Use the same mir-opt bless targets on all platforms
This undoes some of the implementation in https://github.com/rust-lang/rust/pull/119035, but not the effect. Sorry for the churn, I've learned a lot about how all this works over the past few weeks.
The objective here is to make `x test mir-opt --bless` use the same set of targets on all platforms. It didn't do that from the start because bootstrap assumes that a target linker is available, so the availability of cross-linkers is how we ended up with `MIR_OPT_BLESS_TARGET_MAPPING` and poor support for blessing mir-opt tests from Aarch64 MacOS. This PR corrects that.
So I've adjusted the bless targets for mir-opt tests, as well as tweaked some of the logic in bootstrap about linker configuration so that we don't try to access the cache of cc/linker configuration when doing the mir-opt builds.
While working on that I realized that if I swapped from the `cargo rustc -p std` strategy to `cargo check` on the sysroot, I could use the existing code for check builds to bypass some linker logic. Sweet.
But just doing that doesn't work, because then mir-opt tests complain that they can't find an rlib for any of the standard library crates. That happens because nearly all the mir-opt tests are attempting to build `CrateType::Executable`. We already have all the MIR required for mir-opt tests from the rmeta files, but since rustc think we're trying to build an executable it demands we have access to all the upstream monomorphizations that only exist in rlibs, not the meta files in a MIR-only sysroot.
So to fix that, I've swapped all the mir-opt tests be passed `--crate-type=rlib`. That works, but leaves us with a few broken mir-opt tests which I've blessed or fixed up; we also lose MIR for some functions so I added `-Clink-dead-code` to paper over that. The inlining changes are because changing the crate-type perturbs the hashes that are compared here to sometimes let us do inlining even in a possibly-recursive call: 4cb17b4e78/compiler/rustc_mir_transform/src/inline.rs (L332-L341)
Switch OwnedStore handle count to AtomicU32
This is already panics if overflowing a u32, so let's use the smaller int size to save a tiny bit of memory.
- In `emit_producing_error_guaranteed`, only allow `Level::Error`.
- In `emit_diagnostic`, only produce `ErrorGuaranteed` for `Level` and
`DelayedBug`. (Not `Bug` or `Fatal`. They don't need it, because the
relevant `emit` methods abort.)
- Add/update various comments.
`main_args` calls `from_matches`, which does lots of initialization. If
anything goes wrong, `from_matches` emits an error message and returns
`Err(1)` (or `Err(3)`). `main_args` then turns the `Err(1)` into
`Err(ErrorGuaranteed)`, because that's what `catch_with_exit_code`
requires on error. But `catch_with_exit_code` doesn't do anything with
the `ErrorGuaranteed`, it just exits with `EXIT_FAILURE`.
We can avoid the creation of the `ErrorGuaranteed` (which requires
an undesirable `unchecked_claim_error_was_emitted` call), by changing
`from_matches` to instead eagerly abort if anything goes wrong. The
behaviour from the user's point of view is the same: an early abort with
an `EXIT_FAILURE` exit code.
And we can also simplify `from_matches` to return an `Option` instead of
a `Result`:
- Old `Err(0)` case --> `None`
- Old `Err(_)` case --> fatal error.
This requires similar changes to `ScrapeExamplesOptions::new` and
`load_call_locations`.
By making non-unicode arguments a fatal error instead of a warning, we
don't need to handle what comes after, which avoids the need for an
`unchecked_claim_error_was_emitted` call.
When `catch_fatal_errors` catches a `FatalErrorMarker`, it returns an
`ErrorGuaranteed` that is conjured out of thin air with
`unchecked_claim_error_was_emitted`. But that `ErrorGuaranteed` is never
used.
This commit changes it to instead conjure a `FatalError` out of thin
air. (A non-deprecated action!) This makes more sense because
`FatalError` and `FatalErrorMarker` are a natural pairing -- a
`FatalErrorMarker` is created by calling `FatalError::raise`, so this is
effectively getting back the original `FatalError`.
This requires a tiny change in `catch_with_exit_code`. The old result of
the `catch_fatal_errors` call there was
`Result<Result<(), ErrorGuaranteed>, ErrorGuaranteed>` which could be
`flatten`ed into `Result<(), ErrorGuaranteed>`. The new result of the
`catch_fatal_errors` calls is
`Result<Result<(), ErrorGuaranteed>, FatalError>`, which can't be
`flatten`ed but is still easily matched for the success case.
Rollup of 9 pull requests
Successful merges:
- #119939 (Improve 'generic param from outer item' error for `Self` and inside `static`/`const` items)
- #120331 (pattern_analysis: use a plain `Vec` in `DeconstructedPat`)
- #120396 (Account for unbounded type param receiver in suggestions)
- #120423 (update indirect structural match lints to match RFC and to show up for dependencies)
- #120435 (Suggest name value cfg when only value is used for check-cfg)
- #120502 (Remove `ffi_returns_twice` feature)
- #120507 (Account for non-overlapping unmet trait bounds in suggestion)
- #120513 (Normalize type outlives obligations in NLL for new solver)
- #120707 (Don't expect early-bound region to be local when reporting errors in RPITIT well-formedness)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't expect early-bound region to be local when reporting errors in RPITIT well-formedness
The implicit lifetime in the example code gets replaced with `ReError`, which fails a `sub_regions` check in the lexical region solver. Error reporting ends up calling `is_suitable_region` on an early bound region in the *trait* definition. This causes an ICE because we `expect_local()`.
This is kind of a bad explanation, but this code just makes diagnostics reporting a bit more gracefully fallible. If the reviewer wants a thorough investigation of exactly where we get this region outlives obligation, I can write one up. Doesn't really seem worth it, though, imo.
Fixes#120638Fixes#120648
Normalize type outlives obligations in NLL for new solver
Normalize the type outlives assumptions and obligations in MIR borrowck. This should fix any of the lazy-norm-related MIR borrowck problems.
Also some cleanups from last PR:
1. Normalize obligations in a loop in lexical region resolution
2. Use `deeply_normalize_with_skipped_universes` in lexical resolution since we may have, e.g. `for<'a> Alias<'a>: 'b`.
r? lcnr
Account for non-overlapping unmet trait bounds in suggestion
When a method not found on a type parameter could have been provided by any
of multiple traits, suggest each trait individually, instead of a single
suggestion to restrict the type parameter with *all* of them.
Before:
```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
--> $DIR/method-on-unbounded-type-param.rs:5:10
|
LL | (&a).cmp(&b)
| ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
|
= note: the following trait bounds were not satisfied:
`T: Ord`
which is required by `&T: Ord`
`&T: Iterator`
which is required by `&mut &T: Iterator`
`T: Iterator`
which is required by `&mut T: Iterator`
help: consider restricting the type parameters to satisfy the trait bounds
|
LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord {
| +++++++++++++++++++++++++
```
After:
```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
--> $DIR/method-on-unbounded-type-param.rs:5:10
|
LL | (&a).cmp(&b)
| ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
|
= note: the following trait bounds were not satisfied:
`T: Ord`
which is required by `&T: Ord`
`&T: Iterator`
which is required by `&mut &T: Iterator`
`T: Iterator`
which is required by `&mut T: Iterator`
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
|
LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
| +++++
LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
| ++++++++++
```
Fix#108428.
Follow up to #120396, only last commit is relevant.
update indirect structural match lints to match RFC and to show up for dependencies
This is a large step towards implementing https://github.com/rust-lang/rfcs/pull/3535.
We currently have five lints related to "the structural match situation":
- nontrivial_structural_match
- indirect_structural_match
- pointer_structural_match
- const_patterns_without_partial_eq
- illegal_floating_point_literal_pattern
This PR concerns the first 3 of them. (The 4th already is set up to show for dependencies, and the 5th is removed by https://github.com/rust-lang/rust/pull/116284.) nontrivial_structural_match is being removed as per the RFC; the other two are enabled to show up in dependencies.
Fixes https://github.com/rust-lang/rust/issues/73448 by removing the affected analysis.
Account for unbounded type param receiver in suggestions
When encountering
```rust
fn f<T>(a: T, b: T) -> std::cmp::Ordering {
a.cmp(&b) //~ ERROR E0599
}
```
output
```
error[E0599]: no method named `cmp` found for type parameter `T` in the current scope
--> $DIR/method-on-unbounded-type-param.rs:2:7
|
LL | fn f<T>(a: T, b: T) -> std::cmp::Ordering {
| - method `cmp` not found for this type parameter
LL | a.cmp(&b)
| ^^^ method cannot be called on `T` due to unsatisfied trait bounds
|
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
|
LL | fn f<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
| +++++
LL | fn f<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
| ++++++++++
```
Fix#120186.
pattern_analysis: use a plain `Vec` in `DeconstructedPat`
The use of an arena-allocated slice in `DeconstructedPat` dates to when we needed the arena anyway for lifetime reasons. Now that we don't, I'm thinking that if `thir::Pat` can use plain old `Vec`s, maybe so can I.
r? ```@ghost```
revert stabilization of const_intrinsic_copy
`@rust-lang/wg-const-eval` I don't know what we were thinking when we approved https://github.com/rust-lang/rust/pull/97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call `copy` in const on stable since `&mut` expressions are generally unstable. However, there's one exception...
```rust
static mut INT: i32 = unsafe {
let val = &mut [1]; // `&mut` on arrays is allowed in `static mut`
(val as *mut [i32; 1]).copy_from(&[42], 1);
val[0]
};
fn main() { unsafe {
dbg!(INT);
} }
```
Inside `static mut`, we accept some `&mut` since ~forever, to make `static mut FOO: &mut [T] = &mut [...];` work. We reject any attempt to actually write to that mutable reference though... except for the `copy` functions.
I think we should revert stabilizing these functions that take `*mut`, and then re-stabilize them together with `ptr.write` once mutable references are stable.
(This will likely fail on PowerPC until https://github.com/rust-lang/stdarch/pull/1497 lands. But we'll need a crater run first anyway.)
Rollup of 12 pull requests
Successful merges:
- #120520 (Some cleanups around diagnostic levels.)
- #120575 (Simplify codegen diagnostic handling)
- #120597 (Suggest `[tail @ ..]` on `[..tail]` and `[...tail]` where `tail` is unresolved)
- #120602 (rustc_monomorphize: fix outdated comment in partition)
- #120609 (hir: Stop keeping prefixes for most of `use` list stems)
- #120631 (Emit a diagnostic for invalid target options)
- #120632 (For E0223, suggest associated functions that are similar to the path)
- #120670 (cleanup effect var handling)
- #120673 (rustc_metadata: fix typo)
- #120683 (miri: fix ICE with symbolic alignment check on extern static)
- #120690 (Remove b-naber from the compiler review rotation)
- #120713 (Make async closures test use async bound modifier)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove b-naber from the compiler review rotation
They have been inactive for over two months and occasionally S-waiting-on-review PRs didn't get reviewed for a while. I've stolen a few of them.
I've discussed this with `@b-naber` in private and they agreed to leave the review rotation for now.
Thank you very much for all the helpful PR reviews you did in the past! <3
r? compiler
