Fix normalization overflow ICEs in monomorphization
Fixesrust-lang/rust#92004Fixesrust-lang/rust#92470Fixesrust-lang/rust#95134Fixesrust-lang/rust#105275Fixesrust-lang/rust#105937
Fixes rust-lang/rust#117696-2
Fixesrust-lang/rust#118590Fixesrust-lang/rust#122823Fixesrust-lang/rust#131342Fixesrust-lang/rust#139659
## Analysis:
The causes of these issues are similar. They contain generic recursive functions that can be instantiated with different args infinitely at monomorphization stage.
Ideally this should be caught by the [`check_recursion_limit`](c0bb3b98bb/compiler/rustc_monomorphize/src/collector.rs (L468)) function. The reality is that normalization can reach recursion limit earlier than monomorphization's check because they calculate depths in different ways.
Since normalization is called everywhere, ICEs appear in different locations.
## Fix:
If we abort on overflow with `TypingMode::PostAnalysis` in the trait solver, it would also catch these errors.
The main challenge is providing good diagnostics for them. So it's quite natural to put the check right before these normalization happening.
I first tried to check the whole MIR body's normalization and `references_error`. (As elaborate_drop handles normalization failure by [returning `ty::Error`](c0bb3b98bb/compiler/rustc_mir_transform/src/elaborate_drop.rs (L514-L519)).)
It turns out that checking all `Local`s seems sufficient.
These types are gonna be normalized anyway. So with cache, these checks shouldn't be expensive.
This fixes these ICEs for both the next and old solver, though I'm not sure the change I made to the old solver is proper. Its overflow handling looks convoluted thus I didn't try to fix it more "upstream".
Perform unused assignment and unused variables lints on MIR.
Rebase of https://github.com/rust-lang/rust/pull/101500
Fixes https://github.com/rust-lang/rust/issues/51003.
The first commit moves detection of uninhabited types from the current liveness pass to MIR building.
In order to keep the same level of diagnostics, I had to instrument MIR a little more:
- keep for which original local a guard local is created;
- store in the `VarBindingForm` the list of introducer places and whether this was a shorthand pattern.
I am not very proud of the handling of self-assignments. The proposed scheme is in two parts: first detect probable self-assignments, by pattern matching on MIR, and second treat them specially during dataflow analysis. I welcome ideas.
Please review carefully the changes in tests. There are many small changes to behaviour, and I'm not sure all of them are desirable.
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#4 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Validate CopyForDeref and DerefTemps better and remove them from runtime MIR
(split from my WIP rust-lang/rust#145344)
This PR:
- Removes `Rvalue::CopyForDeref` and `LocalInfo::DerefTemp` from runtime MIR
- Using a new mir pass `EraseDerefTemps`
- `CopyForDeref(x)` is turned into `Use(Copy(x))`
- `DerefTemp` is turned into `Boring`
- Not sure if this part is actually necessary, it made more sense in rust-lang/rust#145344 with `DerefTemp` storing actual data that I wanted to keep from having to be kept in sync with the rest of the body in runtime MIR
- Checks in validation that `CopyForDeref` and `DerefTemp` are only used together
- Removes special handling for `CopyForDeref` from many places
- Removes `CopyForDeref` from `custom_mir` reverting rust-lang/rust#111587
- In runtime MIR simple copies can be used instead
- In post cleanup analysis MIR it was already wrong to use due to the lack of support for creating `DerefTemp` locals
- Possibly this should be its own PR?
- Adds an argument to `deref_finder` to avoid creating new `DerefTemp`s and `CopyForDeref` in runtime MIR.
- Ideally we would just avoid making intermediate derefs instead of fixing it at the end of a pass / during shim building
- Removes some usages of `deref_finder` that I found out don't actually do anything
r? oli-obk
Remove StatementKind::Deinit.
It is a remnant from the time we deaggreated MIR.
Now, it is only constructed by the `LargeEnums` MIR pass, which is disabled by default.
Regression test for const promotion with Option<Ordering>
https://rust.godbolt.org/z/EjxqE8WcTFixesrust-lang/rust#139093
Add a regression test to ensure that comparing `Option<Ordering>` to
`Some(Ordering::Equal)` does not trigger unnecessary const promotion
in MIR.
Previously, inlined constants like `Some(Ordering::Equal)` would get
promoted, leading to more complex MIR and redundant LLVM IR checks.
This test verifies that both the direct form and the `let`-binding form
now generate equivalent, simplified MIR.
r? cjgillot
cmse: improve error messages
tracking issue: https://github.com/rust-lang/rust/issues/81391
tracking issue: https://github.com/rust-lang/rust/issues/75835
Improves the cmse error messages (e.g. by using more accurate spans), and attempts to clean up the control flow a bit. This is partially in preparation for one final addition: warnings when `union` types or types with niches cross the security boundary. That will be a folllow-up.
Meant to be reviewed commit-by-commit
r? ``@davidtwco``
Set the minimum deployment target for `aarch64-apple-watchos`
To match what's done in LLVM 21 and Xcode 26, watchOS 26 is the first OS version that actually runs true Aarch64 binaries. This affects the object files we create, and the linker invocation when using `-Clinker=ld`.
See also investigation in https://github.com/rust-lang/rust/issues/147223.
Fix double warnings on `#[no_mangle]`
Fixes 2 out of 3 cases in https://github.com/rust-lang/rust/issues/147417
The fix on closures removes the old error and marks closures as an error target.
The fix on consts adds `AllowSilent` to to ignore a target, and uses the old error because that one has a nice suggestion.
r? ````@jdonszelmann````
clarify wording of match ergonomics diagnostics (`rust_2024_incompatible_pat` lint and error)
Partially addresses rust-lang/rust#143557:
- Uses different wording than the Edition Guide chapter, to hopefully stand alone a bit better. Instead of referring to the "default binding mode", it now talks about what can't be written "within elided reference patterns". I ended up going with "elided" instead of "implicit" in hope that it reads bit less like it should behave the same as an explicit reference pattern, but I'm not totally happy with that wording.
- The explanatory note still points to where the default binding mode was introduced, but only refers to its effect, not what we call it. How that relates to the rest of the diagnostic may still be a bit of a puzzle, but hopefully it isn't too much of one? It also doesn't make sense anymore for the case of `&` written under a by-ref binding mode, so I've left the note out in that case (but kept the label). It's more cramped, but talking about binding modes would feel like a non-sequitur for the error about `&` patterns without further explanation.
- Links to the stable version of the Edition Guide instead of the nightly version. It looks like almost every link to the Edition Guide in diagnostics is to the nightly version, presumably for the same reason as here: the diagnostics were added before the new Edition was stabilized, then never updated. I'll make a separate PR to clean up the others.
This only changes the diagnostic messages, not the code suggestion or the Edition Guide.
r? `@Nadrieril` or reassign
sort attribute targets for more consistent error messages
In this PR I noticed that we don't sort attribute targets, so a rather trivial change to the source changed the ordering in an error message even though its meaning stayed the same.
See: https://github.com/rust-lang/rust/pull/147418#discussion_r2410852750
I think sorting might be a good thing to do in general. I also prefer it when reading error messages. Quite a few tests changed, but not in meaning, only sorting order obviously.
r? `@jieyouxu`
Use globals instead of metadata for std::autodiff
LLVM's Metadata is quite fragile. In debug builds we use incremental compilation, which caused the metadata to be dropped. With this change we use named globals instead of metadata to instruct Enzyme how to differentiate functions.
Globals are proper llvm values and thus can't be dropped. Also added an incremental/dbg test which now passes, to unblock the EnzymeAD CI which wants to run Rust autodiff tests.
r? compiler
