While it shares more than zero code with the SysV x86-32 ABI impl,
there is no particular reason to organize wildly different ABIs
using if-else in the same function.
Support raw-dylib link kind on ELF
raw-dylib is a link kind that allows rustc to link against a library without having any library files present.
This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future.
This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27
Tracking issue: #135694
r? bjorn3
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
raw-dylib is a link kind that allows rustc to link against a library
without having any library files present.
This currently only exists on Windows. rustc will take all the symbols
from raw-dylib link blocks and put them in an import library, where they
can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient
to have this same functionality. Not having the libraries present at
build-time can be convenient for several reasons, especially
cross-compilation. With raw-dylib, code linking against a library can be
cross-compiled without needing to have these libraries available on the
build machine. If the libc crate makes use of this, it would allow
cross-compilation without having any libc available on the build
machine. This is not yet possible with this implementation, at least
against libc's like glibc that use symbol versioning.
The raw-dylib kind could be extended with support for symbol versioning
in the future.
This implementation is very experimental and I have not tested it very
well. I have tested it for a toy example and the lz4-sys crate, where it
was able to successfully link a binary despite not having a
corresponding library at build-time.
add more `s390x` target features
Closes#88937
tracking issue: https://github.com/rust-lang/rust/issues/130869
The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel (and `/proc/cpuinfo`) uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`.
There are a number of implied target features between the vector facilities (based on the [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table):
- 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
- 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
- 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
- 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
- 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
- 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
- 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.
The remaining facilities do not have any implied target features (that we provide):
- 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
- 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
- 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
- 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
- 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.
The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](d49a2d2bc9/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`.
I'll also update the `is_s390x_feature_supported` macro (added in https://github.com/rust-lang/stdarch/pull/1699, not yet on nightly, that needs an stdarch sync) to include these target features.
``@Amanieu`` you had some reservations about the `"vector"` target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the `neural-network-processing-assist` even LLVM thought that was a bit much and shortened it to `nnp-assist`. Also for `vector-packed-decimal-enhancement facility 1` the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation.
r? ``@Amanieu``
cc ``@uweigand`` ``@taiki-e``
The target feature names are, right now, based on the llvm target feature names. These mostly line up well with the names of [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`.
There are a number of implied target features between the vector facilities (based on the [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table):
- 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode.
- 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one.
- 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one.
- 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one.
- 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one.
- 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one.
- 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one.
And then there are a number of facilities without any implied target features
- 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode.
- 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one.
- 133 The guarded-storage facility is installed in the z/Architecture architectural mode.
- 150 The enhanced-sort facility is installed in the z/Architecture architectural mode.
- 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode.
The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](d49a2d2bc9/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`.
Make x86 QNX target name consistent with other Rust targets
Rename target to be consistent with other Rust targets: Use `i686` instead of `i586`
See also
- #136495
- #109173
CC: `@jonathanpallant` `@japaric` `@gh-tr` `@samkearney`
Workaround Cranelift not yet properly supporting vectors smaller than 128bit
While it would technically be possible to workaround this in cg_clif, it quickly becomes very messy and would likely cause correctness issues. Working around it in rustc instead is much simper and won't have any negative impact for code running on stable as vectors smaller than 128bit can only be made on nightly using core::simd or #[repr(simd)].
Do not ignore uninhabited types for function-call ABI purposes. (Remove BackendRepr::Uninhabited)
Accepted MCP: https://github.com/rust-lang/compiler-team/issues/832Fixes#135802
Do not consider the inhabitedness of a type for function call ABI purposes.
* Remove the [`rustc_abi::BackendRepr::Uninhabited`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html) variant
* Instead calculate the `BackendRepr` of uninhabited types "normally" (as though they were not uninhabited "at the top level", but still considering inhabitedness of variants to determine enum layout, etc)
* Add an `uninhabited: bool` field to [`rustc_abi::LayoutData`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/struct.LayoutData.html) so inhabitedness of a `LayoutData` can still be queried when necessary (e.g. when determining if an enum variant needs a tag value allocated to it).
This should not affect type layouts (size/align/field offset); this should only affect function call ABI, and only of uninhabited types.
cc ``@RalfJung``
infer linker flavor by linker name if it's sufficiently specific
Fix: `rustc` does not infer `llvm-bitcode-linker` uses `llbc` linker flavor if targeting `nvptx64-nvidia-cuda`.
Create a generic AVR target: avr-none
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-none` variant that must be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`).
Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official 🙂
Related discussions:
- https://github.com/rust-lang/rust/pull/131171
- https://github.com/rust-lang/compiler-team/issues/800
try-job: x86_64-gnu-debug
This updates the Fuchsia target spec with the [Clang Fuchsia driver],
which picks up a few changes:
* Adds `-z start-stop-visibility=hidden` and `-z rel` to the pre link
arguments.
* Adds `--execute-only` and `--fix-cortex-a53-843419` for
`aarch64-unknown-fuchsia`.
* Enables the cpu features equivalent to x86-64-v2 for
`x86_64-unknown-fuchsia`, which is our minimum supported x86_64.
platform according to [RFC-0073].
* Enables the cpu features `+crc,+aes,+sha2,+neon` on aarch64.
* Increases the max atomic width on 86_64 to 128.
* Enables stack probes and xray on aarch64 and riscv64.
[Clang Fuchsia driver]: 8374d42186/clang/lib/Driver/ToolChains/Fuchsia.cpp
[RFC-0073]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0073_x86_64_platform_requirement
While it would technically be possible to workaround this in cg_clif, it
quickly becomes very messy and would likely cause correctness issues.
Working around it in rustc instead is much simper and won't have any
negative impact for code running on stable as vectors smaller than
128bit can only be made on nightly using core::simd or #[repr(simd)].
This commit removes the `avr-unknown-gnu-atmega328` target and replaces
it with a more generic `avr-none` variant that must be specialized with
the `-C target-cpu` flag (e.g. `-C target-cpu=atmega328p`).
Remove SSE ABI from i586-pc-windows-msvc
As an i586 target, it should not have SSE. This caused the following warning to be emitted:
```
warning: target feature `sse2` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
warning: 1 warning emitted
```
see #116344.
r? RalfJung
As an i586 target, it should not have SSE. This caused the following
warning to be emitted:
```
warning: target feature `sse2` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
warning: 1 warning emitted
```
Load all builtin targets at once instead of one by one in check-cfg
This PR adds a method on `rustc_target::Target` to load all the builtin targets at once, and then uses that method when constructing the `target_*` values in check-cfg instead of load loading each target one by one by their name, which requires a lookup and was more of a hack anyway.
This may give us some performance improvements as we won't need to do the lookup for the _currently_ 287 targets we have.
nvptx64: update default alignment to match LLVM 21
This changed in llvm/llvm-project@91cb8f5d32. The commit itself is mostly about some intrinsic instructions, but as an aside it also mentions something about addrspace for tensor memory, which I believe is what this string is telling us.
`@rustbot` label: +llvm-main
compiler: give `ExternAbi` truly stable `Hash` and `Ord`
Currently, `ExternAbi` has a bunch of code to handle the reality that, as an enum, adding more variants to it will risk it hashing differently. It forces all of those variants to be added in a fixed order, except this means that the order of the variants doesn't correspond to any logical order except "historical accident". This is all to avoid having to rebless two tests. Perhaps there were more, once upon a time? But then we invented normalization in our test suite to handle exactly this sort of issue in a more general way.
There are two options here:
- Get rid of all the logical overhead and shrug, embracing blessing a couple of tests sometimes
- Change `ExternAbi` to have an ordering and hash that doesn't depend on the number of variants
As `ExternAbi` is essentially a strongly-typed string, and thus no two strings can be identical, this implements the second of the two by hand-implementing `Ord` and `Hash` to make the hashing and comparison based on the string! This will diff the current hashes, but they will diff no more after this.
i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change
As per ``@maurer's`` [comment](https://github.com/rust-lang/rust/issues/136495#issuecomment-2648743078), this shouldn't actually change anything since we anyway add a bunch of extensions that bump things up way beyond Pentium 4. But Pentium 4 is consistent with the other i686 targets and I don't know enough about the exact sequence of CPU generations to be confident with more than this. ;)
compiler: die immediately instead of handling unknown target codegen
We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
show supported register classes in error message
a simple diagnostic change that shows the supported register classes when an invalid one is found.
This information can be hard to find (especially for unstable targets), and this message now gives at least something to try or search for. I've followed the pattern for invalid clobber ABIs.
`@rustbot` label +A-inline-assembly
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was added.
This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
```
This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.
CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
It is speculated that these two can be conceptually merged, and it can
start by ripping out rustc's notion of the PtxKernel call convention.
Leave the ExternAbi for now, but the nvptx target now should see it as
just a different way to spell Conv::GpuKernel.
Add amdgpu target
Add amdgpu target to rustc and enable the LLVM target.
Fix compiling `core` with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. `bitcast` is invalid for this
case, `addrspacecast` needs to be used.
Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an `addrspacecast` under the hood)
instead.
MCP: https://github.com/rust-lang/compiler-team/issues/823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.
It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer
> than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was
added.
This warning only occurs with the i686 UEFI target, not x86_64 or
aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but
i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in
`i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets
provide a separate PDB file for debugging. Disable DWARF (and by
extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
compiler: mostly-finish `rustc_abi` updates
This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available.
r? ```@compiler-errors```
compiler: Clean up weird `rustc_abi` reexports
Just general cleanup in `rustc_target` and `rustc_abi`. I was originally going to make a PR with a larger change that also fixed the last few crates and in doing so removed some clutter from `rustc_abi`, but wound up slightly stuck on it, then figured out how to fix it, and then got distracted by other things... so now I'm trying to figure out what I had figured out earlier.
rustc_target has had a lot of weird reexports for various reasons, but
now we're at a point where we can actually start reducing their number.
We remove weird shadowing-dependent behavior and import directly from
rustc_abi instead of doing weird renaming imports.
This is only incremental progress and does not entirely fix the crate.
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
This changed in llvm/llvm-project@91cb8f5d32.
The commit itself is mostly about some intrinsic instructions, but as an
aside it also mentions something about addrspace for tensor memory,
which I believe is what this string is telling us.
@rustbot label: +llvm-main
Add `kl` and `widekl` target features, and the feature gate
This is an effort towards #134813. This PR adds the target-features and the feature gate to `rustc`
<!--
```@rustbot``` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
Explicitly choose x86 softfloat/hardfloat ABI
Part of https://github.com/rust-lang/rust/pull/135408:
Instead of choosing this based on the target features listed in the target spec, make that choice explicit.
All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
Target option to require explicit cpu
Some targets have many different CPUs and no generic CPU that can be used as a default. For these targets, the user needs to explicitly specify a CPU through `-C target-cpu=`.
Add an option for targets and an error message if no CPU is set.
This affects the proposed amdgpu and avr targets.
amdgpu tracking issue: #135024
AVR MCP: https://github.com/rust-lang/compiler-team/issues/800
Reject unsound toggling of Arm atomics-32 target feature
This target feature has the same semantics as RISC-V `forced-atomics` target feature that already marked as Forbidden (f5ed0cb217) and toggling it can cause ABI incompatibility.
2f348cb7ce/compiler/rustc_target/src/target_features.rs (L479-L483)
[Comment on feature definition in LLVM](7109f52197/llvm/lib/Target/ARM/ARMFeatures.td (L572-L574)) also says:
> Code built with this feature is not ABI-compatible with code built without this feature, if atomic variables are exposed across the ABI boundary.
r? `@workingjubilee` or `@RalfJung`
`@rustbot` label +O-Arm
ABI-required target features: warn when they are missing in base CPU
Part of https://github.com/rust-lang/rust/pull/135408:
instead of adding ABI-required features to the target we build for LLVM, check that they are already there. Crucially we check this after applying `-Ctarget-cpu` and `-Ctarget-feature`, by reading `sess.unstable_target_features`. This means we can tweak the ABI target feature check without changing the behavior for any existing user; they will get warnings but the target features behave as before.
The test changes here show that we are un-doing the "add all required target features" part. Without the full #135408, there is no way to take a way an ABI-required target feature with `-Ctarget-cpu`, so we cannot yet test that part.
Cc ``@workingjubilee``
Windows x86: Change i128 to return via the vector ABI
Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C.
In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW.
Link: https://github.com/rust-lang/rust/issues/134288 (does not fix) [1]
try-job: x86_64-msvc
try-job: x86_64-msvc-ext1
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
Clang and GCC both return `i128` in xmm0 on windows-msvc and
windows-gnu. Currently, Rust returns the type on the stack. Add a
calling convention adjustment so we also return scalar `i128`s using the
vector ABI, which makes our `i128` compatible with C.
In the future, Clang may change to return `i128` on the stack for its
`-msvc` targets (more at [1]). If this happens, the change here will
need to be adjusted to only affect MinGW.
Link: https://github.com/rust-lang/rust/issues/134288
This method will be removed in the future as it produces a broken ABI
that depends on cg_llvm implementation details. After this PR
wasm32-unknown-unknown is the only remaining user of
make_direct_deprecated().
Rollup of 7 pull requests
Successful merges:
- #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only))
- #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets)
- #135812 (Fix GDB `OsString` provider on Windows )
- #135842 (TRPL: more backward-compatible Edition changes)
- #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting)
- #135953 (ci.py: check the return code in `run-local`)
- #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
compiler: Set `target_abi = "ilp32e"` on all riscv32e targets
This allows compile-time configuration based on this. In the near future we should do this across all RISCV targets, probably, but this cfg is essential for building software usable on these targets, and they are tier 3 so it seems less of a concern to tweak their definition thusly.
use `PassMode::Direct` for vector types on `s390x`
closes https://github.com/rust-lang/rust/issues/135744
tracking issue: https://github.com/rust-lang/rust/issues/130869
Previously, all vector types were type erased to `Ni8`, now we pass non-wrapped vector types directly. That skips emitting a bunch of casting logic in rustc, that LLVM then has to clean up. The initial LLVM IR is also a bit more readable.
This calling convention is tested extensively in `tests/assembly/s390x-vector-abi.rs`, showing that this change has no impact on the ABI in practice.
r? ````@taiki-e````
Rollup of 8 pull requests
Successful merges:
- #133605 (Add extensive set of drop order tests)
- #135489 (remove pointless allowed_through_unstable_modules on TryFromSliceError)
- #135757 (Add NuttX support for AArch64 and ARMv7-A targets)
- #135799 (rustdoc-json: Rename `Path::name` to `path`, and give it the path again.)
- #135865 (For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.)
- #135890 (Implement `VecDeque::pop_front_if` & `VecDeque::pop_back_if`)
- #135914 (Remove usages of `QueryNormalizer` in the compiler)
- #135936 (fix reify-intrinsic test)
r? `@ghost`
`@rustbot` modify labels: rollup
Add NuttX support for AArch64 and ARMv7-A targets
This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including:
- AArch64 target: aarch64-unknown-nuttx
- ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf
- Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf
Enable kernel sanitizers for aarch64-unknown-none-softfloat
We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use.
cc ```@rcvalle``` ```@ojeda``` ```@maurer```
Update windows-gnu targets to set `DebuginfoKind::DWARF`
These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo.
This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers.
cc ````@mati865```` since you mentioned this in #135739
cc ````@davidtwco```` for split-dwarf
AIX: use align 8 for byval parameter
On AIX, byval pointer arguments are aligned to 8 bytes based on the 64bit register size. For example, the C callee https://godbolt.org/z/5f4vnG6bh will expect the following argument.
```
ptr nocapture noundef readonly byval(%struct.TwoU64s) align 8 %0
```
This case is captured by `run-make/extern-fn-explicit-align`
These targets have always generated DWARF debuginfo and not CodeView/PDB debuginfo
like the MSVC Windows targets. Correct their target definitions to reflect this.
The newly added tests for the various combinations of `*-windows-gnu*` targets and
`-Csplit-debuginfo` show that this does not change any stable behavior.
Add gpu-kernel calling convention
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target.
Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
Tracking issue: #135467
amdgpu target tracking issue: #135024
Some targets have many different CPUs and no generic CPU that can be
used as a default. For these targets, the user needs to explicitly
specify a CPU through `-C target-cpu=`.
Add an option for targets and an error message if no CPU is set.
This affects the proposed amdgpu and avr targets.
The amdgpu-kernel calling convention was reverted in commit
f6b21e90d1 due to inactivity in the amdgpu
target.
Introduce a `gpu-kernel` calling convention that translates to
`ptx_kernel` or `amdgpu_kernel`, depending on the target that rust
compiles for.
Add new `{x86_64,i686}-win7-windows-gnu` targets
These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.
> ## Tier 3 target policy
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [Major Change Proposal (MCP)][https://forge.rust-lang.org/compiler/mcp.html].
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
> maintainers") on record to be CCed when issues arise regarding the target.
> (The mechanism to track and CC such developers may evolve over time.)
This is me, `@tbu-` on github.
> - Targets must use naming consistent with any existing targets; for instance, a
> target for the same CPU or OS as an existing Rust target should use the same
> name for that CPU or OS. Targets should normally use the same names and
> naming conventions as used elsewhere in the broader ecosystem beyond Rust
> (such as in other toolchains), unless they have a very good reason to
> diverge. Changing the name of a target can be highly disruptive, especially
> once the target reaches a higher tier, so getting the name right is important
> even for a tier 3 target.
> - Target names should not introduce undue confusion or ambiguity unless
> absolutely necessary to maintain ecosystem compatibility. For example, if
> the name of the target makes people extremely likely to form incorrect
> beliefs about what it targets, the name should be changed or augmented to
> disambiguate it.
> - If possible, use only letters, numbers, dashes and underscores for the name.
> Periods (`.`) are known to cause issues in Cargo.
Consistent with `{x86_64,i686}-win7-windows-msvc`, see also #118150.
> - Tier 3 targets may have unusual requirements to build or use, but must not
> create legal issues or impose onerous legal terms for the Rust project or for
> Rust developers or users.
> - The target must not introduce license incompatibilities.
> - Anything added to the Rust repository must be under the standard Rust
> license (`MIT OR Apache-2.0`).
> - The target must not cause the Rust tools or libraries built for any other
> host (even when supporting cross-compilation to the target) to depend
> on any new dependency less permissive than the Rust licensing policy. This
> applies whether the dependency is a Rust crate that would require adding
> new license exceptions (as specified by the `tidy` tool in the
> rust-lang/rust repository), or whether the dependency is a native library
> or binary. In other words, the introduction of the target must not cause a
> user installing or running a version of Rust or the Rust tools to be
> subject to any new license requirements.
> - Compiling, linking, and emitting functional binaries, libraries, or other
> code for the target (whether hosted on the target itself or cross-compiling
> from another target) must not depend on proprietary (non-FOSS) libraries.
> Host tools built for the target itself may depend on the ordinary runtime
> libraries supplied by the platform and commonly used by other applications
> built for the target, but those libraries must not be required for code
> generation for the target; cross-compilation to the target must not require
> such libraries at all. For instance, `rustc` built for the target may
> depend on a common proprietary C runtime library or console output library,
> but must not depend on a proprietary code generation library or code
> optimization library. Rust's license permits such combinations, but the
> Rust project has no interest in maintaining such combinations within the
> scope of Rust itself, even at tier 3.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
> legal/licensing terms include but are *not* limited to: non-disclosure
> requirements, non-compete requirements, contributor license agreements
> (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
> requirements conditional on the employer or employment of any particular
> Rust developers, revocable terms, any requirements that create liability
> for the Rust project or its developers or users, or any requirements that
> adversely affect the livelihood or prospects of the Rust project or its
> developers or users.
AFAICT, it's the same legal situation as the tier 1 `{x86_64,i686}-pc-windows-gnu`.
> - Neither this policy nor any decisions made regarding targets shall create any
> binding agreement or estoppel by any party. If any member of an approving
> Rust team serves as one of the maintainers of a target, or has any legal or
> employment requirement (explicit or implicit) that might affect their
> decisions regarding a target, they must recuse themselves from any approval
> decisions regarding the target's tier status, though they may otherwise
> participate in discussions.
> - This requirement does not prevent part or all of this policy from being
> cited in an explicit contract or work agreement (e.g. to implement or
> maintain support for a target). This requirement exists to ensure that a
> developer or team responsible for reviewing and approving a target does not
> face any legal threats or obligations that would prevent them from freely
> exercising their judgment in such approval, even if such judgment involves
> subjective matters or goes beyond the letter of these requirements.
Understood.
> - Tier 3 targets should attempt to implement as much of the standard libraries
> as possible and appropriate (`core` for most targets, `alloc` for targets
> that can support dynamic memory allocation, `std` for targets with an
> operating system or equivalent layer of system-provided functionality), but
> may leave some code unimplemented (either unavailable or stubbed out as
> appropriate), whether because the target makes it impossible to implement or
> challenging to implement. The authors of pull requests are not obligated to
> avoid calling any portions of the standard library on the basis of a tier 3
> target not implementing those portions.
This target supports the whole libstd surface, since it's essentially reusing all of the x86_64-pc-windows-gnu target. Understood.
> - The target must provide documentation for the Rust community explaining how
> to build for the target, using cross-compilation if possible. If the target
> supports running binaries, or running tests (even if they do not pass), the
> documentation must explain how to run such binaries or tests for the target,
> using emulation if possible or dedicated hardware if necessary.
I tried to write some documentation on that.
> - Tier 3 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to maintain the target. In particular,
> do not post comments (automated or manual) on a PR that derail or suggest a
> block on the PR based on a tier 3 target. Do not send automated messages or
> notifications (via any medium, including via ``@`)` to a PR author or others
> involved with a PR regarding a tier 3 target, unless they have opted into
> such messages.
> - Backlinks such as those generated by the issue/PR tracker when linking to
> an issue or PR are not considered a violation of this policy, within
> reason. However, such messages (even on a separate repository) must not
> generate notifications to anyone involved with a PR who has not requested
> such notifications.
Understood.
> - Patches adding or updating tier 3 targets must not break any existing tier 2
> or tier 1 target, and must not knowingly break another tier 3 target without
> approval of either the compiler team or the maintainers of the other tier 3
> target.
> - In particular, this may come up when working on closely related targets,
> such as variations of the same architecture with different features. Avoid
> introducing unconditional uses of features that another variation of the
> target may not have; use conditional compilation or runtime detection, as
> appropriate, to let each target run code supported by that target.
> - Tier 3 targets must be able to produce assembly using at least one of
> rustc's supported backends from any host target. (Having support in a fork
> of the backend is not sufficient, it must be upstream.)
Understood.
> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
>
Understood.
r? compiler-team
arm: add unstable soft-float target feature
This has an actual usecase as mentioned [here](https://github.com/rust-lang/rust/issues/116344#issuecomment-2575324988), and with my recent ARM float ABI changes there shouldn't be any soundness concerns any more. We will reject enabling this feature on `hf` targets, but disabling it on non-`hf` targets is entirely fine -- the target feature refers to whether softfloat emulation is used for float instructions, and is independent of the ABI which we set separately via `llvm_floatabi`.
Cc ``@workingjubilee``
add m68k-unknown-none-elf target
r? `@workingjubilee`
The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.
I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
Add a notion of "some ABIs require certain target features"
I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.
We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.
For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)
As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.
r? `@workingjubilee`
Target: Add mips mti baremetal support
Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
Do the same thing as gcc, which use the vendor `mti` to mark
the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
Improve default target options for x86_64-unknown-linux-none
Without a standard library, we cannot unwind, so it should be panic=abort by default.
Additionally, it does not have std because while it is Linux, it cannot use libc, which std uses today for Linux.
Using PIE by default may be surprising to users, as shown in #134763, so I've documented it explicitly. I'm not sure if we want to count that as fixing the issue or not.
cc `@morr0ne,` as you added the target (and are the maintainer), and `@Noratrieb,` who reviewed that PR (:D).
Without a standard library, we cannot unwind, so it should be
panic=abort by default.
Additionally, it does not have std because while it is
Linux, it cannot use libc, which std uses today for Linux.
