Support `x test --stage 1 ui-fulldeps`
`@Nilstrieb` had an excellent idea the other day: the same way that rustdoc is able to load `rustc_driver` from the sysroot, ui-fulldeps tests should also be able to load it from the sysroot. That allows us to run fulldeps tests with stage1, without having to fully rebuild the compiler twice. It does unfortunately have the downside that we're building the tests with the *bootstrap* compiler, not the in-tree sources, but since most of the fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of the running compile to match the ABI of the compiler linked with `rustc_driver`. As a result they can't be supported in stage 1 and have to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage 2 build to load rustc_driver, it's primarily testing the error message that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That allows running `hash-stable-is-unstable` in stage1, since it now suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the correct version of std.
- Move a few lint tests from ui-fulldeps to ui
These had an `aux-build:lint-group-plugin-test.rs` that they never actually loaded with `feature(plugin)` nor tested. I removed the unused aux-build and they pass fine with stage 1.
Fixes https://github.com/rust-lang/rust/issues/75905.
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
Check freeze with right param-env in `deduced_param_attrs`
We're checking if a trait (`Freeze`) holds in a polymorphic function, but not using that function's own (reveal-all) param-env. This causes us to try to eagerly normalize a specializable projection type that has no default value, which causes an ICE.
Fixes#110171
Remove `remap_env_constness` in queries
This removes some of the complexities with const traits. #88119 used to be caused by this but was fixed by `param_env = param_env.without_const()`.
Update some ignored tests.
This unignores some tests which no longer need to be ignored (see individual commits for reasons why). This also adds some descriptions to why tests are ignored so they can be seen in the test output.
suggest lifetime for closure parameter type when mismatch
This is a draft PR, will add test cases later and be ready for review.
This PR fixes https://github.com/rust-lang/rust/issues/105675 by adding a diagnostics suggestion. Also a partial fix to https://github.com/rust-lang/rust/issues/105528.
The following code will have a compile error now:
```
fn const_if_unit(input: bool) -> impl for<'a> FnOnce(&'a ()) -> usize {
let x = |_| 1;
x
}
```
Before this PR:
```
error[E0308]: mismatched types
--> src/lib.rs:3:5
|
3 | x
| ^ one type is more general than the other
|
= note: expected trait `for<'a> FnOnce<(&'a (),)>`
found trait `FnOnce<(&(),)>`
note: this closure does not fulfill the lifetime requirements
--> src/lib.rs:2:13
|
2 | let x = |_| 1;
| ^^^
error: implementation of `FnOnce` is not general enough
--> src/lib.rs:3:5
|
3 | x
| ^ implementation of `FnOnce` is not general enough
|
= note: closure with signature `fn(&'2 ()) -> usize` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`...
= note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `rust-test` due to 2 previous errors
```
After this PR:
```
error[E0308]: mismatched types
--> src/lib.rs:3:5
|
3 | x
| ^ one type is more general than the other
|
= note: expected trait `for<'a> FnOnce<(&'a (),)>`
found trait `FnOnce<(&(),)>`
note: this closure does not fulfill the lifetime requirements
--> src/lib.rs:2:13
|
2 | let x = |_| 1;
| ^^^
help: consider changing the type of the closure parameters
|
2 | let x = |_: &_| 1;
| ~~~~~~~
error: implementation of `FnOnce` is not general enough
--> src/lib.rs:3:5
|
3 | x
| ^ implementation of `FnOnce` is not general enough
|
= note: closure with signature `fn(&'2 ()) -> usize` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`...
= note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `rust-test` due to 2 previous errors
```
After applying the suggestion, it compiles. The suggestion might not always be correct as the generation procedure of that suggestion is quite simple...
This test was ignored long ago in
https://github.com/rust-lang/rust/pull/20578/ when the syntax for
closures was changed.
The current status is that a closure with an explicit `!` return type
will trigger the `unreachable_code` lint which appears to be the
original intent of the test
(https://github.com/rust-lang/rust/pull/16836). A closure without a
return type won't trigger the lint since the `!` type isn't inferred
(AFAIK). This restores the test to its original form.
Do not attempt to commute comparison and cast to codegen discriminants
The general algorithm to compute a discriminant is:
```
relative_tag = tag - niche_start
is_niche = relative_tag <= (ule) relative_max
discr = if is_niche {
cast(relative_tag) + niche_variants.start()
} else {
untagged_variant
}
```
We have an optimization branch which attempts to merge the addition and the subtraction by commuting them with the cast. We currently get this optimization wrong.
This PR takes the easiest and safest way: remove the optimization, and let LLVM handle it. (Perf may not agree with that course of action 😅)
There may be a less invasive solution, but I don't have the necessary knowledge of LLVM semantics to find it. Cranelift has the same optimization, which should be handled similarly.
cc `@nikic` and `@bjorn3` if you have a better solution.
Fixes https://github.com/rust-lang/rust/issues/110128
Reformulate `point_at_expr_source_of_inferred_type` to be more accurate
Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation.
This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!)
This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear.
r? `@estebank`
Remove all but one of the spans in `BoundRegionKind::BrAnon`
There are only three places where `BoundRegionKind::BrAnon` uses `Some(span)` instead of `None`. Two of them are easy to remove, which this PR does.
r? ```@jackh726```
don't uniquify regions when canonicalizing
uniquifying causes a bunch of issues, most notably it causes `AliasEq(<?x as Trait<'a>>::Assoc, <?x as Trait<'a>>::Assoc)` to result in ambiguity because both `normalizes-to` paths result in ambiguity and substs equate should trivially succeed but doesn't because we uniquified `'a` to two different regions.
I originally added uniquification to make it easier to deal with requirement 6 from the dev-guide: https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html#requirements
> ### 6. Trait solving must be (free) lifetime agnostic
>
> Trait solving during codegen should have the same result as during typeck. As we erase
> all free regions during codegen we must not rely on them during typeck. A noteworthy example
> is special behavior for `'static`.
cc https://github.com/rust-lang/rustc-dev-guide/pull/1671
Relying on regions being identical may cause ICE during MIR typeck, but even without this PR we can end up relying on that as type inference vars can resolve to types which contain an identical region. Let's land this and deal with any ICE that crop up as we go. Will look at this issue again before stabilization.
r? ```@compiler-errors```
Improve safe transmute error reporting
This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for transmutability.
The `std` test straightforwardly can't work without file descriptors;
#99417 tracks moving it out of tests/ui.
`issue-13560.rs` requires the target to support dynamic linking.
`extern-mod-syntax` is interesting. The original test was added to check
if `extern mod` could be parsed correctly and used `extern mod std` and
an import:
138dc3048a (diff-73700e1e851b7a37bc92174635dab726124c82e5bfabbbc45b4a3c2e8e14fadd)
At some point `std::json::Object` was moved out of std to an unstable
rustc-only `extras` crate, and rather than just changing the import it
got changed to use the unstable crate. When `extras` was removed, people
assumed the test was meant to also test rustc_private and changed it to
another unstable crate rather than using something in std.
This changes the test to remove the `rustc_private` import, to allow it
to work properly when cross-compiling.
This patch updates the error reporting when Safe Transmute is not
possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for
transmutability.
Added diagnostic for pin! macro in addition to Box::pin if Unpin isn't implemented
I made a PR earlier, but accidentally renamed a branch and that deleted the PR... sorry for the duplicate
Currently, if an operation on `Pin<T>` is performed that requires `T` to implement `Unpin`, the diagnostic suggestion is to use `Box::pin` ("note: consider using `Box::pin`").
This PR suggests pin! as well, as that's another valid way of pinning a value, and avoids a heap allocation. Appropriate diagnostic suggestions were included to highlight the difference in semantics (local pinning for pin! vs non-local for Box::pin).
Fixes#109964
Check for body owner fallibly in error reporting
Sometimes the "body id" we use for an obligation cause is not actually a body owner, like when we're doing WF checking on items.
Fixes#110157
