This is the subset of incremental tests that have a FIXME to consider migrating
to check-pass instead.
That migration is beyond the scope of this PR, but might be attempted later.
This is the subset of incremental tests that should continue to use `bpass`
even after `cpass` is supported, because they (presumably) involve codegen.
Long ago, UI tests were divided into "compile" and "run" tests. Later, the
compile tests were further subdivided into "check" and "build" tests, to speed
up tests that don't need a full build.
The same split was never applied to incremental test revisions, so the only way
to perform a check build in incremental tests is (confusingly) to use a `cfail`
revision and then specify `//@ check-fail` or `//@ check-pass`.
This PR makes room for dedicated check-fail and check-pass revisions by
renaming the existing `cfail` and `cpass` revisions to `bfail` and `bpass`,
since they currently perform a full build.
This directive was only being used by one test, which can just as easily use
the more general `//@ failure-status` directive instead.
All of the removed exit-code checks were redundant with other exit-code checks
that are still present.
Incremental revisions beginning with `rfail` would cause the incremental test
runner to build the test program, expecting success, and then run the test
program, expecting failure.
Expecting incremental tests to fail at runtime is of questionable utility,
because in almost all cases an equivalent test program can be made to succeed
at runtime instead.
Removing `rfail` support is a small step towards cleaning up compiletest's
incremental test runner, and its overall handling of pass/fail expectations.
There was one existing regression test using `rfail` revisions:
`tests/incremental/issue-80691-bad-eval-cache.rs`. The test code is complex,
and reverting the fix in RUST-83220 does not actually cause the test to fail,
suggesting that it is no longer a useful regression test. This commit therefore
deletes that test.
This is useful when you have two dependencies that use different trait for
the same thing and with the same name. The user can accidentally implement
the bad one which might be confusing. This commits refactorizes existing
diagnostics about multiple different crates with the same version and adds
a note when similarly named traits are found. All diagnostics are merged
into a single one.
Marks ADT live if it appears in pattern
Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).
Fixesrust-lang/rust#120770
Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
These tests just need blessing, they don't have any interesting behaviour
changes.
Some of these tests have new errors because `LegacyReceiver` cannot be
proven to be implemented now that it is also testing for `MetaSized` -
but this is just a consequence of the other errors in the test.
Encode synthetic by-move coroutine body with a different `DefPathData`
See the included test. In the first revision rpass1, we have an async closure `{closure#0}` which has a coroutine as a child `{closure#0}::{closure#0}`. We synthesize a by-move coroutine body, which is `{closure#0}::{closure#1}` which depends on the mir_built query, which depends on the typeck query.
In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision: `{closure#0}::{closure#1}`. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle.
The problem here is that we really should never have used the same `DefPathData` for the synthetic by-move coroutine body, since it's not a closure. Changing the `DefPathData` will mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle.
Fixes#139142
Add environment variable query
Generally, `rustc` prefers command-line arguments, but in some cases, an environment variable really is the most sensible option. We should make sure that this works properly with the compiler's change-tracking mechanisms, such that changing the relevant environment variable causes a rebuild.
This PR is a first step forwards in doing that.
Part of the work needed to do https://github.com/rust-lang/rust/issues/118204, see https://github.com/rust-lang/rust/pull/129342 for some discussion.
r? ``@petrochenkov``
This currently works because it's part of expansion, and that isn't yet
tracked by the query system. But we want to ensure it continues working,
even if that is changed.
Zalathar