Port `#[thread_local]` to attribute parser
Simple port, only thing that might be an issue is the `help: #[thread_local] can be applied to foreign statics and statics` it probably would be that if an attribute is applicable to both statics and foreign statics that we don't alphabetically sort them next to each other, because now it kinda reads like `#[thread_local]` is something that you primarily use on foreign statics
r? `@JonathanBrouwer`
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).
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
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
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.
All usages of `memory_index` start by calling `invert_bijective_mapping`, so
storing the inverted mapping directly saves some work and simplifies the code.
Subtree sync for rustc_codegen_cranelift
Nothing too exciting since the last sync.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres
r? ``@jieyouxu`` (since you looked at the other one)
Fixes https://github.com/rust-lang/rust/issues/149982
Previously a [fix was proposed](https://github.com/rust-lang/rust/pull/149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.
Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.
Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.
The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.
Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3
The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
Guillaume Gomez