Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature
gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and
GCC backends fall back to the platform default since they have no
equivalent.
Support `-Cpanic=unwind` on WASI targets
This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here).
* The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too.
The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets.
Finally, this ends up closing rust-lang/rust#154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against.
Closesrust-lang/rust#154593
This commit is some minor updates/restructuring in a few locations with
the end result being supporting `-Cpanic=unwind` on WASI targets. This
continues to be off-by-default insofar as WASI targets default to
`-Cpanic=abort`, meaning that actually using anything in this commit
requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of
`libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also
updated here).
* The `unwind` crate here in this repository uses the `libunwind` module
instead of the custom bare-metal wasm implementation of exceptions.
This means that Rust uses the `_Unwind_*` symbols which allows it to
interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument
`-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of
using the legacy exception handling proposal for WebAssembly. This has
no effect by default because `panic=abort` is used on most targets.
Emscripten is exempted from this as the Emscripten target is
explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the
`panic_unwind` crate which ended up requiring `-Wexceptions` from
Wasmtime, so the test parts were updated and Wasmtime was updated in
CI, too.
The net result of all of this is that this should not actually affect
any WebAssembly target's default behavior. Optionally, though, WASI
programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary
to enable this support on wasm targets.
Finally, this ends up closing 154593 as well. The WASI targets are now
defined to use `-lunwind` to implement unwinding. This means that the
in-tree definition of `__cpp_exception` is no longer of concern and the
definition is always sourced externally. If Rust is linked with other
C/C++ code using WASI then these idioms are compatible with wasi-sdk,
for example, to use that as a linker. The main caveat is that when using
an external linker the `-fwasm-exceptions` argument needs to be passed
to `clang` for it to be able to find the `libunwind.a` library to link
against.
Closes 154593
[AIX] add -bdbg:namedsects:ss link arg
On AIX, the PGO runtime and ifunc runtime support requires the named section linker feature which collects the name sections together and generates start/stop symbols for them.
This change adds the option to the default linker args for the target.
`rustc`: `target_features`: allow for `cfg`-only stable `target_features`
This PR introduces a new stabilization level for `target_features`: `CfgOnlyStable`. The motivation is allowing the Rust compiler to expose `target_features` of targets so users can use `cfg(target_feature = "feature")` for conditional blocks depending on target features. However, `CfgOnlyStable` cannot be used for `#[target_feature(enable = "feature")]`, as this is still considered unstable. Accordingly, the compiler will still raise an error if these expressions are used on stable.
This PR relates partially to rust-lang/rust#150257. As discussed, for RISC-V targets, having the `"d"`, `"e"`, and `"f"` target features exposed will allow baremetal developers to adapt the code depending on the target's properties.
r? @RalfJung
On AIX, PGO runtimes and ifunc support requires the named section linker feature which collects the name sections together and generates start/stop symbols for them.
This change adds the option to the default linker args for the target.
Specifically:
- `HashStable` -> `StableHash` (trait)
- `HashStable` -> `StableHash` (derive)
- `HashStable_NoContext` -> `StableHash_NoContext` (derive)
Note: there are some names in `compiler/rustc_macros/src/hash_stable.rs`
that are still to be renamed, e.g. `HashStableMode`.
Part of MCP 983.
Simplify `HashStable`
This PR:
- Simplifies the `HashStable` trait, by moving its generic parameter from the trait to its single method.
- Eliminates the need for the non-obvious `derive(HashStable)`/`derive(HashStable_Generic)` distinction.
- Reduces the need for, and clarifies, the non-obvious `derive(HashStable)`/`derive(HashStable_NoContext)` distinction.
r? @fee1-dead
Update with new LLVM 22 target for `wasm32-wali-linux-musl` target
This is a reopening of rust-lang/rust#155654, which was closed abruptly due to changed commit SHAs on my end during merge.
NVPTX: Drop support for old architectures and old ISAs
This is the implementation of [this MCP](https://github.com/rust-lang/compiler-team/issues/965#issuecomment-3837320262)
I believe it was said that no FCP was needed, but if that is incorrect then the FCP is anyway scheduled to finish in 2 days so it can in any case be merged then.
[AIX] update linker default to bcdtors
The bcdtor mode affects how the AIX linker choose to pull in static constructors and destructors (https://www.ibm.com/docs/en/aix/7.2.0?topic=l-ld-command) to the link.
The current setting of all makes static init in archive members live regardless of if the archive member would be otherwise referenced, causing that whole archive member to become part of the link.
This default was initially retained for compatibility purposes with historical compilers on the platform which defaulted to this setting. Unfortunately this greedy pulling in of static init can have unintended consequences for applications, for example for programs linked against parts of compiler-rt which contain optional instrumentation (containing static initializers) which may be unused as these now become live in all programs regardless of use.
For that reason and similar reasons, this PR switches the default to mbr, which only extracts static init from archive members which would otherwise be referenced. This gives a behaviour very consistent with linkers on other platforms (e.g. Linux).
Users requiring the old default behaviour can manually pass `-bcdtors:all` on the link step which will override any default we pass here.
(Note: this mirrors LLVM change: https://github.com/llvm/llvm-project/pull/191265)
Fix tier level for 5 thumb bare-metal ARM targets
The spec files for 5 Thumb-mode bare-metal ARM targets incorrectly set tier: Some(2), while the documentation correctly lists them as Tier 3. This mismatch was introduced in PR #150556 — the intent was Tier 2 eventually, but these targets should sit at Tier 3 until a proper Tier 3 → Tier 2 promotion MCP is submitted and approved.
This PR changes tier: Some(2) → Some(3) in the following spec files, making them consistent with the docs:
thumbv7a-none-eabi
thumbv7a-none-eabihf
thumbv7r-none-eabi
thumbv7r-none-eabihf
thumbv8r-none-eabihf
PS: No doc changes needed — they already correctly state Tier 3.
r?
Enable AddressSanitizer on arm-unknown-linux-gnueabihf and armv7-unknown-linux-gnueabihf
Add SanitizerSet::ADDRESS to the supported_sanitizers for the arm-unknown-linux-gnueabihf and armv7-unknown-linux-gnueabihf targets.
The AddressSanitizer is already enabled on the armv7-linux-androideabi platform, which shares the same ARM architecture. There is no reason these Linux GNU targets should not also support it, as the underlying LLVM support for ASan on 32-bit ARM is already in place.
Add SanitizerSet::ADDRESS to the supported_sanitizers for the
arm-unknown-linux-gnueabihf and armv7-unknown-linux-gnueabihf targets.
The AddressSanitizer is already enabled on the armv7-linux-androideabi
platform, which shares the same ARM architecture. There is no reason
these Linux GNU targets should not also support it, as the underlying
LLVM support for ASan on 32-bit ARM is already in place.
preserve SIMD element type information
Preserve the SIMD element type and provide it to LLVM for better optimization.
This is relevant for AArch64 types like `int16x4x2_t`, see also https://github.com/llvm/llvm-project/issues/181514. Such types are defined like so:
```rust
#[repr(simd)]
struct int16x4_t([i16; 4]);
#[repr(C)]
struct int16x4x2_t(pub int16x4_t, pub int16x4_t);
```
Previously this would be translated to the opaque `[2 x <8 x i8>]`, with this PR it is instead `[2 x <4 x i16>]`. That change is not relevant for the ABI, but using the correct type prevents bitcasts that can (indeed, do) confuse the LLVM pattern matcher.
This change will make it possible to implement the deinterleaving loads on AArch64 in a portable way (without neon-specific intrinsics), which means that e.g. Miri or the cranelift backend can run them without additional support.
discussion at [#t-compiler > loss of vector element type information](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/loss.20of.20vector.20element.20type.20information/with/584483611)
Implement `-Z allow-partial-mitigations` (RFC 3855)
This implements `-Z allow-partial-mitigations` as an unstable option, currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo` rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).
r? @rcvalle
The bcdtor mode affects how the AIX linker choose to pull in static constructors and destructors (https://www.ibm.com/docs/en/aix/7.2.0?topic=l-ld-command) to the link.
The current setting of all makes static init in archive members live regardless of if the archive member would be otherwise referenced, causing that whole archive member to become part of the link.
This default was initially retained for compatibility purposes with historical compilers on the platform which defaulted to this setting. Unfortunately this greedy pulling in of static init can have unintended consequences for applications, for example for programs linked against parts of compiler-rt which contain optional instrumentation (containing static initializers) which may be unused as these now become live in all programs regardless of use.
For that reason and similar reasons, this PR switches the default to mbr, which only extracts static init from archive members which would otherwise be referenced. This gives a behaviour very consistent with linkers on other platforms (e.g. Linux).
Users requiring the old default behaviour can manually pass -bcdtors:all on the link step which will override any default we pass here.
allow `windows-gnu` targets to embed gdb visualizer scripts
Pretty straigthforward, works exactly the same as any other `*-gnu` target so i'm not sure why it wasn't enabled already.
Hexagon: add scalar arch-version target features (v60-v79, audio)
Add target features corresponding to Hexagon LLVM CPU generations to complement the existing HVX vector features. These are needed for gating scalar intrinsics by architecture version.
New features: audio, v60, v62, v65, v66, v67, v68, v69, v71, v73, v75, v79
Each version implies the previous (e.g. v68 implies v67 which implies v66, etc.), matching LLVM's ArchV60-ArchV79 subtarget features.
Also adds hexagon revisions to the feature-hierarchy test to verify the implied feature chains work correctly.
Invert dependency between `rustc_errors` and `rustc_abi`.
Currently, `rustc_errors` depends on `rustc_abi`, which depends on `rustc_error_messages`. This is a bit odd.
`rustc_errors` depends on `rustc_abi` for a single reason: `rustc_abi` defines a type `TargetDataLayoutErrors` and `rustc_errors` impls `Diagnostic` for that type.
We can get a more natural relationship by inverting the dependency, moving the `Diagnostic` trait upstream. Then `rustc_abi` defines `TargetDataLayoutErrors` and also impls `Diagnostic` for it. `rustc_errors` is already pretty far upstream in the crate graph, it doesn't hurt to push it a little further because errors are a very low-level concept.
r? @davidtwco
Add target features corresponding to Hexagon LLVM CPU generations to
complement the existing HVX vector features. These are needed for
gating scalar intrinsics by architecture version.
New features: audio, v60, v62, v65, v66, v67, v68, v69, v71, v73, v75, v79
Each version implies the previous (e.g. v68 implies v67 which implies
v66, etc.), matching LLVM's ArchV60-ArchV79 subtarget features.
Also adds hexagon revisions to the feature-hierarchy test to verify
the implied feature chains work correctly.
This implements `-Z allow-partial-mitigations` as an unstable option,
currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo`
rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy
way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a
better policy is possible (bikeshed).
rustc: Stop passing `--allow-undefined` on wasm targets
This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added.
At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null:
unsafe extern "C" {
static nonexistent: u8;
}
fn main() {
println!("{:?}", &raw const nonexistent);
}
This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected:
#[link(wasm_import_module = "host")]
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program:
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.
Dirkjan Ochtman