miri genmc: fix exit() handling
In genmc mode, Miri does not want to stop execution when `exit` is called. Instead we want to continue running other threads to ensure we covered all possible concurrent behaviors (including the ones where the exiting thread was delayed so the other threads took their turns first). However, the core interpreter has a sanity check that prevents us from just doing nothing in `exit`. This leaves us in a pickle: there's nowhere we can jump to (exit has return type `!` so there's no next block), but if we don't jump anywhere we ICE.
The first commit fixes that by disabling the sanity check when there is no block to jump to. That still catches the mistake of forgetting to jump for the vast majority of shims.
We currently don't build Miri's genmc integration in rustc CI so I had to hack the feature into the bootstrap miri integration. That turned out to use the wrong Miri binary, which is fixed by the second commit: we can just rely on CARGO_BIN_EXE_miri, there's no need for a MIRI environment variable.
r? ``@oli-obk``
rustc_codegen_llvm: Tidying of `update_target_reliable_float_cfg`
This PR simplifies floating type handling through `update_target_reliable_float_cfg` based on several facts:
1. Major changes in behavior normally occurs only on the major LLVM upgrade.
2. The first release of LLVM 20.x.x is 20.1.0.
Due to the first fact, we can normally ignore minor and patch releases of LLVM and we can remove obscure variables like `lt_xx_x_x`.
The second fact is missed when the minimum LLVM version is raised to LLVM 20 (cf. rust-lang/rust#145071) and one "fixed in LLVM 20" case can be safely removed (another cannot be removed since it's fixed on LLVM 20.1.1).
It also reorders certain `match` clauses by the architecture when there's no problems reordering it.
Note that, an LLVM issue on MIPS is fixed on LLVM 20.1.**0** and another on AArch64 is fixed on LLVM 20.1.**1**.
Originally, they are both considered fixed on LLVM 20.1.**1** but the author separated them into two cases (so that the MIPS bug checking can be removed).
Update cargo submodule
13 commits in e91b2baa632c0c7e84216c91ecfe107c37d887c1..3861f60f6b58f57524c0e7aab1f5c1ad83e35409
2025-12-13 16:29:21 +0000 to 2025-12-19 21:53:33 +0000
- fix(sbom): Don't set CARGO_SBOM_PATH when empty (like stable) (rust-lang/cargo#16419)
- chore(ci): report-timings to upload HTML report (rust-lang/cargo#16416)
- fix(report): get the same feature parity of `--timings` (rust-lang/cargo#16414)
- fix(docs): Document the only possible values for DEBUG in build scripts (rust-lang/cargo#16413)
- fix(log): emit fingeprint log also for no-rebuild unit (rust-lang/cargo#16408)
- Fix link to `doc_cfg` docs in cargo book (rust-lang/cargo#16404)
- Add best pratice for how to check in generated files (rust-lang/cargo#16405)
- test: Use a larger default term width (rust-lang/cargo#16403)
- Document more services and permissions of the cargo team (rust-lang/cargo#16402)
- fix(new): Improve quality of package name error messages (rust-lang/cargo#16398)
- feat(log): add more log events (rust-lang/cargo#16390)
- chore: bump to 0.95.0; update changelog (rust-lang/cargo#16395)
- Cache submodule into git db (rust-lang/cargo#16246)
r? ghost
This commit simplifies floating type handling through
`update_target_reliable_float_cfg` based on several facts:
1. Major changes in behavior normally occurs only
on the major LLVM upgrade.
2. The first release of LLVM 20.x.x is 20.1.0.
Due to the first fact, we can normally ignore minor and patch releases
of LLVM and we can remove obscure variables like `lt_xx_x_x` (still,
there is a case where checking for patch version is required).
The second fact is missed when the minimum LLVM version is raised to
LLVM 20 and one "fixed in LLVM 20" case can be safely removed.
... in `update_target_reliable_float_cfg`, based on the actual changes.
The AArch64 issue is fixed on LLVM 20.1.1 while the MIPS issue is fixed
on LLVM 20.1.0 (the first LLVM 20 release).
This commit distinguishes two separate cases.
Split eii macro expansion code
r? jonathanbrouwer (since you did the last one too, should be quite trivial)
While investigating rust-lang/rust#149980 I decided this code deserved some splitting :)
layout: Store inverse memory index in `FieldsShape::Arbitrary`
All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
rustc_target: Add `efiapi` ABI support for LoongArch
This commit adds basic `efiapi` ABI support for LoongArch by recognizing `extern "efiapi"` in the ABI map and inline asm clobber handling, and mapping it to the C calling convention.
This change is intentionally submitted ahead of the full LoongArch UEFI target support. While UEFI binaries are ultimately produced as PE images, LoongArch UEFI applications can already be developed by building ELF objects, applying relocation fixups, and converting them to PE in a later step. For such workflows, having `efiapi` properly recognized by the compiler is a prerequisite, even without a dedicated UEFI target.
Landing this ABI support early helps unblock LoongArch UEFI application and driver development, and allows the remaining UEFI-specific pieces to be introduced incrementally in follow-up patches.
MCP: https://github.com/rust-lang/compiler-team/issues/953
Improve filenames encoding and misc
This PR is a follow-up to https://github.com/rust-lang/rust/pull/149709, it aims at preventing a double encoding when there are no remapping, as well as making some small improvements to the code.
Best reviewed commit by commit.
Move shared offload globals and define per-kernel globals once
This PR moves the shared LLVM global variables logic out of the `offload` intrinsic codegen and generates kernel-specific variables only ont he first call of the intrinsic.
r? `@ZuseZ4`
tracking:
- https://github.com/rust-lang/rust/issues/131513
Enable `outline-atomics` by default on AArch64 FreeBSD
Many aarch64 targets without LSE in the baseline enable the
`outline-atomics` feature, which uses runtime detection of LSE for its
faster atomic ops. This provides nontrivial performance improvements on
most hardware from the past decade, at a small cost to anything pre-LSE.
This matches what Clang does [1].
Context: https://github.com/rust-lang/rust/pull/144938
[1]: https://github.com/llvm/llvm-project/commit/e24f90190c772b6fdd915cd0a2e55cbd468c3024
try-job: dist-x86_64-freebsd
Perf regression fix
The only thing changed from the previous PR is that I removed `output_is_inhabited` from hot path, and hide it behind condition, so now it will compute it less frequent
follow up on https://github.com/rust-lang/rust/pull/149664
move eii tests
Just a little housekeeping. This feature is getting a lot of tests, so it felt good to put some tests for type checking in its own folder to organise a little. Should be trivial!
mir_build: Don't use a mixture of THIR pattern kinds for pin-patterns
While looking for improvements to match-lowering, I had been trying to figure out why pin-patterns sometimes use `PatKind::Deref` and sometimes use `PatKind::DerefPattern`, which seemed confusing to me. In particular, both pattern kinds are being used with an inner type of `&` or `&mut`, which is very surprising.
The conclusion I came to was that `DerefPattern` (normally associated with calls to Deref/DerefMut) was only being used for *implicit* pin-patterns produced by match-ergonomics adjustment, whereas `Deref` was being used for explicit pin-patterns.
The inconsistency seems like a mistake to me, so this PR removes all uses of `DerefPattern` for pin-patterns, and consistently uses `PatKind::Deref` for pin-patterns instead. I'm not entirely happy with that outcome, because I think pin-patterns should probably have their own `thir::PatKind` variant, but this change will at least make that easier to achieve in a later PR.
r? Nadrieril
Prefer remapping the relative `library/` and `compiler/` directories
This is done to avoid leaking the relative paths to the standard library after the overall of filenames in rust-lang/rust#149709.
Noted that the paths were already leaking before, but to a lesser extent since most (but not all) the paths embedded in the distributed `rlib` were absolute.
In general Cargo compiles workspace members with relative paths, so it's better anyway to remap the relative path.
In addition to our tests I have manually confirmed that it also works as expected for the printed diagnostics paths.
cf. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/remapping.20of.20the.20standard.20library/near/564093571
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#147430 (cg_llvm: More preparation for moving FFI bindings to `rustc_llvm`)
- rust-lang/rust#149815 (Add regression test for rust-lang/rust#120189)
- rust-lang/rust#150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #120189
This PR adds regression tests for rust-lang/rust#120189.
I added tests to verify vectorization of loops inside closures.
Don't treat asserts as a call in cross-crate inlining
Making functions with calls in their bodies automatically cross-crate-inlinable tends to tank incremental build times. Though assert terminators are _like_ calls, they don't exhibit the same behavior.
Justin Geibel