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.
Replace `LLVMRustContextCreate` with normal LLVM-C API calls
Since `LLVMRustContextCreate` can easily be replaced with a call to `LLVMContextCreate` and `LLVMContextSetDiscardValueNames`.
Work towards https://github.com/rust-lang/rust/issues/46437
Extract most code from `define_feedable!`
This PR extracts most of the non-trivial code from the `define_feedable!` macro (which defines the `TyCtxtFeed::$query` methods), and moves it to a helper function `query_feed_inner` written in ordinary non-macro code.
Doing so should make that code easier to read and modify, because it now gets proper IDE support and has explicit trait bounds.
---
There should be no change in compiler behaviour.
I've structured the commits so that the actual extraction part is mostly just whitespace changes, making it easier to review individually with whitespace changes hidden.
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.
Promote armv7a-none-eabihf to Tier 2
This PR promotes armv7a-none-eabihf to Tier 2, to join armv7r-none-eabihf and armv7a-none-eabi. I believe it was simply an oversight that it wasn't made Tier 2 before, as most Armv7-A targets have an FPU and it often makes sense to use it.
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
> - A tier 2 target must have value to people other than its maintainers. (It may
> still be a niche target, but it must not be exclusively useful for an
> inherently closed group.)
The `armv7a-none-eabihf` target is for all Arm Cortex-A processors (either 32-bit only, or in 32-bit mode) where the user wants to use the FPU.
>- A tier 2 target must have a designated team of developers (the "target
> maintainers") available to consult on target-specific build-breaking issues,
> or if necessary to develop target-specific language or library implementation
> details. This team must have at least 2 developers.
The Embedded Devices Working Group's Arm Team have just started maintaining this target.
> - The target must not place undue burden on Rust developers not specifically
> concerned with that target. Rust developers are expected to not gratuitously
> break a tier 2 target, but are not expected to become experts in every tier 2
> target, and are not expected to provide target-specific implementations for
> every tier 2 target.
This target is highly similar to a number of existing Tier 2 targets, including `armv7r-none-eabihf` and `armv7a-none-eabi` and so it should not add undue burden.
> - The target must provide documentation for the Rust community explaining how
> to build for the target using cross-compilation, and explaining how to run
> tests for the target. If at all possible, this documentation should show how
> to run Rust programs and tests for the target using emulation, to allow
> anyone to do so. If the target cannot be feasibly emulated, the documentation
> should explain how to obtain and work with physical hardware, cloud systems,
> or equivalent.
https://doc.rust-lang.org/nightly/rustc/platform-support/armv7a-none-eabi.html was added in https://github.com/rust-lang/rust/pull/146419/. It covers the `-eabi` and the `-eabihf` targets.
> - The target must document its baseline expectations for the features or
> versions of CPUs, operating systems, libraries, runtime environments, and
> similar.
I believe it does.
> - If introducing a new tier 2 or higher target that is identical to an existing
> Rust target except for the baseline expectations for the features or versions
> of CPUs, operating systems, libraries, runtime environments, and similar,
> then the proposed target must document to the satisfaction of the approving
> teams why the specific difference in baseline expectations provides
> sufficient value to justify a separate target.
It uses very similar FPUs to `armv7r-none-eabihf` but is otherwise the same as `armv7a-none-eabi`.
> - Tier 2 targets must not leave any significant portions of `core` or the
> standard library unimplemented or stubbed out, unless they cannot possibly be
> supported on the target.
It has a full libcore, as per the other arm*-none-* targets.
> - The code generation backend for the target should not have deficiencies that
> invalidate Rust safety properties, as evaluated by the Rust compiler team.
It should be the same backend as `armv7r-none-eabihf` and friends, except for FPU support, which is already covered in `thumbv8m.main-none-eabihf`. There are no issues that I know of.
> - If the target supports C code, and the target has an interoperable calling
> convention for C code, the Rust target must support that C calling convention
> for the platform via `extern "C"`. The C calling convention does not need to
> be the default Rust calling convention for the target, however.
The ABI is EABI, the same as many other Arm targets.
> - The target must build reliably in CI, for all components that Rust's CI
> considers mandatory.
The https://github.com/rust-embedded/cortex-ar repository has been changed in https://github.com/rust-embedded/cortex-ar/pull/57 to build this target with `-Zbuild-std=core`. Locally it seems fine.
> - The approving teams may additionally require that a subset of tests pass in
> CI, such as enough to build a functional "hello world" program, `./x.py test
> --no-run`, or equivalent "smoke tests". In particular, this requirement may
> apply if the target builds host tools, or if the tests in question provide
> substantial value via early detection of critical problems.
There are no no-std tests in the tree that I'm aware of.
> - Building the target in CI must not take substantially longer than the current
> slowest target in CI, and should not substantially raise the maintenance
> burden of the CI infrastructure. This requirement is subjective, to be
> evaluated by the infrastructure team, and will take the community importance
> of the target into account.
Building libcore is quite fast.
> - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
> targets should not require using the target as the host for builds, even if
> the target supports host tools.
It does.
> - In addition to the legal requirements for all targets (specified in the tier
> 3 requirements), because a tier 2 target typically involves the Rust project
> building and supplying various compiled binaries, incorporating the target
> and redistributing any resulting compiled binaries (e.g. built libraries,
> host tools if any) must not impose any onerous license requirements on any
> members of the Rust project, including infrastructure team members and those
> operating CI systems. This is a subjective requirement, to be evaluated by
> the approving teams.
Just libcore required (and liballoc). No known issues here.
> - Tier 2 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to ensure that tests pass for the target.
Noted
> - The target maintainers should regularly run the testsuite for the target
The https://github.com/rust-embedded/cortex-ar repository will be changed to use the rustup component when available.
> and should fix any test failures in a reasonably timely fashion.
Noted
Promote armv8r-none-eabihf target to Tier 2
This PR promotes armv8r-none-eabihf to Tier 2, joining armv7r-none-eabi, armv7r-none-eabihf and armv7a-none-eabi.
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
> - A tier 2 target must have value to people other than its maintainers. (It may
> still be a niche target, but it must not be exclusively useful for an
> inherently closed group.)
The `armv8r-none-eabihf` target is for the Arm Cortex-R52 processor, as found in a number of Automotive SoCs that have just been released, or are about to be released. Currently SoCs are available from NXP and Renesas.
>- A tier 2 target must have a designated team of developers (the "target
> maintainers") available to consult on target-specific build-breaking issues,
> or if necessary to develop target-specific language or library implementation
> details. This team must have at least 2 developers.
The Embedded Devices Working Group's Arm Team have just started maintaining this target.
> - The target must not place undue burden on Rust developers not specifically
> concerned with that target. Rust developers are expected to not gratuitously
> break a tier 2 target, but are not expected to become experts in every tier 2
> target, and are not expected to provide target-specific implementations for
> every tier 2 target.
This target is highly similar to a number of existing Tier 2 targets, including `armv7r-none-eabihf` and so it should not add undue burden.
> - The target must provide documentation for the Rust community explaining how
> to build for the target using cross-compilation, and explaining how to run
> tests for the target. If at all possible, this documentation should show how
> to run Rust programs and tests for the target using emulation, to allow
> anyone to do so. If the target cannot be feasibly emulated, the documentation
> should explain how to obtain and work with physical hardware, cloud systems,
> or equivalent.
https://doc.rust-lang.org/nightly/rustc/platform-support/armv8r-none-eabihf.html exists and was updated in https://github.com/rust-lang/rust/pull/146419/
> - The target must document its baseline expectations for the features or
> versions of CPUs, operating systems, libraries, runtime environments, and
> similar.
I believe it does.
> - If introducing a new tier 2 or higher target that is identical to an existing
> Rust target except for the baseline expectations for the features or versions
> of CPUs, operating systems, libraries, runtime environments, and similar,
> then the proposed target must document to the satisfaction of the approving
> teams why the specific difference in baseline expectations provides
> sufficient value to justify a separate target.
The Armv8-R architecture introduces a new FPU type, the fp-armv8, and so this requires a unique target.
> - Tier 2 targets must not leave any significant portions of `core` or the
> standard library unimplemented or stubbed out, unless they cannot possibly be
> supported on the target.
It has a full libcore, as per the other arm*-none-* targets.
> - The code generation backend for the target should not have deficiencies that
> invalidate Rust safety properties, as evaluated by the Rust compiler team.
It should be the same backend as `armv7r-none-eabihf` and friends, except for FPU support, which is already covered in `thumbv8m.main-none-eabihf`. There are no issues that I know of.
> - If the target supports C code, and the target has an interoperable calling
> convention for C code, the Rust target must support that C calling convention
> for the platform via `extern "C"`. The C calling convention does not need to
> be the default Rust calling convention for the target, however.
The ABI is EABI, the same as many other Arm targets.
> - The target must build reliably in CI, for all components that Rust's CI
> considers mandatory.
The https://github.com/rust-embedded/cortex-ar repository regularly builds this target with `-Zbuild-std=core` and it seems fine.
> - The approving teams may additionally require that a subset of tests pass in
> CI, such as enough to build a functional "hello world" program, `./x.py test
> --no-run`, or equivalent "smoke tests". In particular, this requirement may
> apply if the target builds host tools, or if the tests in question provide
> substantial value via early detection of critical problems.
There are no no-std tests in the tree that I'm aware of.
> - Building the target in CI must not take substantially longer than the current
> slowest target in CI, and should not substantially raise the maintenance
> burden of the CI infrastructure. This requirement is subjective, to be
> evaluated by the infrastructure team, and will take the community importance
> of the target into account.
Building libcore is quite fast.
> - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
> targets should not require using the target as the host for builds, even if
> the target supports host tools.
It does.
> - In addition to the legal requirements for all targets (specified in the tier
> 3 requirements), because a tier 2 target typically involves the Rust project
> building and supplying various compiled binaries, incorporating the target
> and redistributing any resulting compiled binaries (e.g. built libraries,
> host tools if any) must not impose any onerous license requirements on any
> members of the Rust project, including infrastructure team members and those
> operating CI systems. This is a subjective requirement, to be evaluated by
> the approving teams.
Just libcore required (and liballoc). No known issues here.
> - Tier 2 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to ensure that tests pass for the target.
Noted
> - The target maintainers should regularly run the testsuite for the target
The https://github.com/rust-embedded/cortex-ar repository will be changed to use the rustup component when available.
> and should fix any test failures in a reasonably timely fashion.
Noted
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.
Perform InstSimplify before ReferencePropagation.
`InstSimplify` clears CFG caches.
But it currently happens between `ReferencePropagation` and `GVN`, which both use dominators, a quite expensive computation.
r? `@ghost`
PassWrapper: use non-deprecated lookupTarget method
This avoids an extra trip through a triple string by directly passing the Triple, and has been available since LLVM 21. The string overload was deprecated today and throws an error on our CI for HEAD due to -Werror paranoia, so we may as well clean this up now and also skip the conversion on LLVM 21 since we can.
`@rustbot` label llvm-main
Prefer to use repeat_n over repeat().take()
More from https://github.com/rust-lang/rust/pull/147464, but batch processed with `ast-grep` to find and replace.
second commit add notes for library: affaf532f9
r? ``@RalfJung``
refactor: Remove `LLVMRustInsertPrivateGlobal` and `define_private_global`
Since it can easily be implemented using the existing LLVM C API in
terms of `LLVMAddGlobal` and `LLVMSetLinkage` and `define_private_global`
was only used in one place.
Work towards https://github.com/rust-lang/rust/issues/46437
Do not invalidate CFG caches in CtfeLimit.
This does not matter much, as no optimization pass runs after `CtfeLimit`, but I still find the code cleaner.
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````
Port the implemention of SIMD intrinsics from Miri to const-eval
Ported the implementation of most SIMD intrinsics from Miri to rustc_const_eval. Remaining are
- Math functions (as per `@RalfJung's` suggestions)
- FMA (non-deterministic)
- Funnel Shifts (not implemented in Miri yet)
- Unordered reduction intrinsics (not implemented in Miri yet)
Refactor AddCallGuards in two loops.
This PR splits the pass into an analysis loop and a change loop. This allows to avoid invalidating CFG caches if there are no changes to be performed.
r? `@ghost` for perf
Since it can easily be implemented using the existing LLVM C API in
terms of `LLVMAddGlobal` and `LLVMSetLinkage` and `define_private_global`
was only used in one place.
GVN: Evaluate constants lazily.
GVN currently evaluates constants eagerly. This is not necessary. This PR makes constant evaluation on-demand to avoid unnecessary work.
r? `@ghost` for perf
