terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)
Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](f25e5abea2/compiler/rustc_passes/messages.ftl (L297-L301))), which aligns better with what "declaring" usually means. To make things worse, the functions `tcx.features().active(...)` and `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]` exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.
So really, our terminology is just a mess.
I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for `#[feature(name)]`. This PR implements that.
Always specify `llvm_abiname` for RISC-V targets
For RISC-V targets, when `llvm_abiname` is not specified LLVM will infer the ABI from the target features, causing #116344 to occur. This PR adds the correct `llvm_abiname` to all RISC-V targets where it is missing (which are all soft-float targets), and adds a test to prevent future RISC-V targets from accidentally omitting `llvm_abiname`. The only affect of this PR is that `-Ctarget-feature=+f` (or similar) will no longer affect the ABI on the modified targets.
<!-- homu-ignore:start -->
r? `@RalfJung`
<!--- homu-ignore:end -->
rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972)
Command line flag `-Zregparm=<N>` for X86 (32-bit) for rust-for-linux: https://github.com/rust-lang/rust/issues/116972
Implemented in the similar way as fastcall/vectorcall support (args are marked InReg if fit).
Migrate `llvm::set_comdat` and `llvm::SetUniqueComdat` to LLVM-C FFI.
Note, now we can call `llvm::set_comdat` only when the target actually
supports adding comdat. As this has no convenient LLVM-C API, we
implement this as `TargetOptions::supports_comdat`.
Co-authored-by: Stuart Cook <Zalathar@users.noreply.github.com>
Setting up indirect access to external data for loongarch64-linux-{musl,ohos}
In issue #118053, the `loongarch64-unknown-linux-gnu` target needs indirection to access external data, and so do the `loongarch64-unknown-linux-musl` and `loongarch64-unknown-linux-ohos` targets.
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR.
This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add
runtime feature detection for it at this time.
LLVM has added 3 new address spaces to support special Windows use
cases. These shouldn't trouble us for now, but LLVM requires matching
data layouts.
See llvm/llvm-project#111879 for details
Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly
Currently `clobber_abi` in Arm64EC inline assembly is implemented using `InlineAsmClobberAbi::AArch64NoX18`, but broken since it attempts to clobber registers that cannot be used in Arm64EC: https://godbolt.org/z/r3PTrGz5r
```
error: cannot use register `x13`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x14`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
<omitted the same errors for v16-v31>
```
Additionally, this disallows SVE-related registers per https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142.
cc ``@dpaoliello``
r? ``@Amanieu``
``@rustbot`` label O-windows O-AArch64 +A-inline-assembly
compiler: `{TyAnd,}Layout` comes home
The `Layout` and `TyAndLayout` types are heavily abstract and have no particular target-specific qualities, though we do use them to answer questions particular to targets. We can keep it that way if we simply move them out of `rustc_target` and into `rustc_abi`. They bring a small entourage of connected types with them, but that's fine.
This will allow us to strengthen a few abstraction barriers over time and thus make the notoriously gnarly layout code easier to refactor. For now, we don't need to worry about that and deliberately use reexports to minimize this particular diff.
In issue #118053, the `loongarch64-unknown-linux-gnu` target needs indirection
to access external data, and so do the `loongarch64-unknown-linux-musl` and
`loongarch64-unknown-linux-ohos` targets.
Support clobber_abi in MSP430 inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf)
cc ``@cr1901``
r? ``@Amanieu``
``@rustbot`` label +O-msp430
ABI: Pass aggregates by value on AIX
On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.
313ad85dfa/clang/lib/CodeGen/Targets/PPC.cpp (L216)
Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Fix `target_vendor` in non-IDF Xtensa ESP32 targets
`rustc`'s Xtensa ESP32 targets are the following:
- `xtensa-esp32-none-elf`
- `xtensa-esp32-espidf`
- `xtensa-esp32s2-none-elf`
- `xtensa-esp32s2-espidf`
- `xtensa-esp32s3-none-elf`
- `xtensa-esp32s3-espidf`
The ESP-IDF targets already set `target_vendor="espressif"`, however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?
Fix `target_abi` in `sparc-unknown-none-elf`
This was previously set to `target_abi = "elf"`, but `elf` is not used elsewhere as a target ABI (even though there's many targets that have it in their name), so I've removed it.
CC target maintainer ``@jonathanpallant,`` what do you think about this?
``@rustbot`` label O-SPARC
Fix `target_env` in `avr-unknown-gnu-atmega328`
The target name itself contains GNU, we should probably reflect that as `target_env = "gnu"` as well? Or from my reading of https://github.com/rust-lang/rust/pull/74941#issuecomment-712219034, perhaps not, but then that should probably be documented somewhere?
There's no listed target maintainer, but the target was introduced in https://github.com/rust-lang/rust/pull/74941, so I'll ping the author of that: `@dylanmckay`
Relatedly, I wonder _why_ the recommendation is to [create separate target triples for each AVR](https://github.com/Rahix/avr-hal/tree/main/avr-specs), when `-Ctarget-cpu=...` would suffice, perhaps you could also elaborate on that? Was it just because `-Ctarget-cpu=...` didn't exist back then? If so, now that it does, should we now change the target back to e.g. `avr-unknown-none-gnu`, and require the user to set `-Ctarget-cpu=...` instead?
Add x86_64-unknown-trusty as tier 3 target
This PR adds a third target for the Trusty platform, `x86_64-unknown-trusty`.
Please let me know if an MCP is required. https://github.com/rust-lang/compiler-team/issues/582 was made when adding the first two targets, I can make another one for the new target as well if needed.
# Target Tier Policy Acknowledgements
> 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.)
- Nicole LeGare (```@randomPoison)```
- Andrei Homescu (```@ahomescu)```
- Chris Wailes (chriswailes@google.com)
- As a fallback trusty-dev-team@google.com can be contacted
Note that this does not reflect the maintainers currently listed in [`trusty.md`](c52c23b6f4/src/doc/rustc/src/platform-support/trusty.md). #130452 is currently open to update the list of maintainers in the documentation.
> 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.
The new target `x86_64-unknown-trusty` follows the existing naming convention for similar targets.
> 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.
👍
> 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.
There are no known legal issues or license incompatibilities.
> 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.
👍
> 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 PR only adds the target. `std` support is being worked on and will be added in a future PR.
> 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.
👍
> 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.
👍
> 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.
👍
> 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.)
👍
This was previously set to `target_abi = "elf"`, but `elf` is not used
elsewhere as a target ABI (even though there's many targets that have it
in their name).
Fix `target_abi` in SOLID targets
The `armv7a-kmc-solid_asp3-eabi` and `armv7a-kmc-solid_asp3-eabihf` targets clearly have the ABI in their name, so it should also be exposed in Rust's `target_abi` cfg variable.
CC target maintainer `@kawadakk.`
Fix `target_vendor` for `aarch64-nintendo-switch-freestanding`
Previously set to `target_vendor = "unknown"`, but Nintendo is clearly the vendor of the Switch, and is also reflected in the target name itself.
CC target maintainers `@leo60228` and `@jam1garner`
Previously set to `target_os = "none"` and `target_env = "psx"`, but
although the Playstation 1 is _close_ to a bare metal target in some
regards, it's still very much an operating system, so we should set
`target_os = "psx"`.
This also matches the `mipsel-sony-psp` target, which sets
`target_os = "psp"`.
The `armv7a-kmc-solid_asp3-eabi` and `armv7a-kmc-solid_asp3-eabihf`
targets clearly have the ABI in their name, so it should also be exposed
in Rust's `target_abi` cfg variable.
The Xtensa ESP32 targets are the following:
- xtensa-esp32-none-elf
- xtensa-esp32-espidf
- xtensa-esp32s2-none-elf
- xtensa-esp32s2-espidf
- xtensa-esp32s3-none-elf
- xtensa-esp32s3-espidf
The ESP-IDF targets already set `target_vendor="espressif"`, however,
the ESP32 is produced by Espressif regardless of whether using the IDF
or not, so we should set the target vendor there as well.
Apple: Do not specify an SDK version in `rlib` object files
This was added in https://github.com/rust-lang/rust/pull/114114, but is unnecessary, since it ends up being overwritten when linking anyhow, and it feels wrong to embed some arbitrary SDK version in here. The object files produced by LLVM also do not set this, and the tooling shows `n/a` when it's `0`, so it seems to genuinely be optional in object files.
I've also added a test for the different places the SDK version shows up, and documented a bit more in the code how SDK versions work.
See https://github.com/rust-lang/rust/issues/129432 for the bigger picture.
Tested with (excludes the same few targets as in https://github.com/rust-lang/rust/pull/130435):
```console
./x test tests/run-make/apple-sdk-version --target aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin
IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-sdk-version --target=i386-apple-ios
```
CC `@BlackHoleFox,` you [originally commented on these values](https://github.com/rust-lang/rust/pull/114114#discussion_r1300599445).
`@rustbot` label O-apple
Move Apple linker args from `rustc_target` to `rustc_codegen_ssa`
They are dependent on the deployment target and SDK version, but having these in `rustc_target` makes it hard to introduce that dependency. Part of the work needed to do https://github.com/rust-lang/rust/issues/118204, see https://github.com/rust-lang/rust/pull/129342 for some discussion.
Tested using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-deployment-target --target=i386-apple-ios
```
`arm64e-apple-darwin` and `arm64e-apple-ios` have not been tested, see https://github.com/rust-lang/rust/issues/130085, neither is `i686-apple-darwin`, since that requires using an x86_64 macbook, and I currently can't get mine to work, see https://github.com/rust-lang/rust/issues/130434.
CC `@petrochenkov`
Fixup Apple target's description strings
Noticed this inconsistency in how the Apple target's had their new descriptions written while looking at https://github.com/rust-lang/rust/pull/130614, and figured it was easy enough to fixup shortly. I think prefixing every OS with `Apple` is clearer, especially for less known ones like `visionOS` and `watchOS`; so that's what was done here along with making the architecture names more consistent and then some other small tweaks.
~~r? `@thomcc~~`
cc `@madsmtm`
The previous name is just an LLVMism, which conveys almost nothing about
what is actually meant by the function relative to the ABI.
In doing so, remove an already-addressed FIXME.
This is a follow-up to #123159, but applied to Armv8-R.
This required https://github.com/llvm/llvm-project/pull/88287 to work
properly. Now that this change exists in rustc's llvm, we can fix
Armv8-R's default fpu features. In Armv8-R's case, the default features
from LLVM for floating-point are sufficient, because there is no
integer-only variant of this architecture.
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
Relands [2]: #120661
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: https://github.com/rust-lang/rust/issues/121289#issuecomment-2333687396
Simplify some nested `if` statements
Applies some but not all instances of `clippy::collapsible_if`. Some ended up looking worse afterwards, though, so I left those out. Also applies instances of `clippy::collapsible_else_if`
Review with whitespace disabled please.
Fix default/minimum deployment target for Aarch64 simulator targets
The minimum that `rustc` encoded did not match [the version in Clang](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.8/llvm/lib/TargetParser/Triple.cpp#L1900-L1932), and that meant that that when linking, Clang ended up bumping the version. See https://github.com/rust-lang/rust/issues/129432 for more motivation behind this change.
Specifically, this PR sets the correct deployment target of the following targets:
- `aarch64-apple-ios-sim` from 10.0 to 14.0
- `aarch64-apple-tvos-sim` from 10.0 to 14.0
- `aarch64-apple-watchos-sim` from 5.0 to 7.0
- `aarch64-apple-ios-macabi` from 13.1 to 14.0
I have chosen not to document the `-sim` changes in the platform support docs, as it is fundamentally uninteresting; the normal targets (e.g. `aarch64-apple-ios`) still have the same deployment target, and that's what developers should actually target.
r? compiler
CC `@BlackHoleFox`
Pass deployment target when linking with CC on Apple targets
This PR effectively implements what's also being considered in the `cc` crate [here](https://github.com/rust-lang/cc-rs/issues/1030#issuecomment-2051020649), that is:
- When linking macOS targets with CC, pass the `-mmacosx-version-min=.` option to specify the desired deployment target. Also, no longer pass `-m32`/`-m64`, these are redundant since we already pass `-arch`.
- When linking with CC on iOS, tvOS, watchOS and visionOS, only pass `-target` (we assume for these targets that CC forwards to Clang).
This is required to get the linker to emit the correct `LC_BUILD_VERSION` of the final binary. See https://github.com/rust-lang/rust/issues/129432 for more motivation behind this change.
r? compiler
CC `@BlackHoleFox`
The Rust LoongArch targets have been using the default LLVM code model
so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak.
As described in the "Code Model" section of LoongArch ELF psABI spec
v20231219 [1], one can only make function calls as far as ±128MiB with
the "normal" code model; this is insufficient for very large software
containing Rust components that needs to be linked into the big text
section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build
such software,
* objects compiled with larger code models can be linked with those
with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one
performance-wise (same data access pattern; each function call
becomes 2-insn long and indirect, but this may be relaxed back into
the direct 1-insn form in a future LLVM version), but is able to
perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model,
which is also "medium" in LLVM-speak.
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
Co-authored-by: WANG Rui <wangrui@loongson.cn>
Add -Z small-data-threshold
This flag allows specifying the threshold size above which LLVM should not consider placing small objects in a `.sdata` or `.sbss` section.
Support is indicated in the target options via the
small-data-threshold-support target option, which can indicate either an
LLVM argument or an LLVM module flag. To avoid duplicate specifications
in a large number of targets, the default value for support is
DefaultForArch, which is translated to a concrete value according to the
target's architecture.
This flag allows specifying the threshold size above which LLVM should
not consider placing small objects in a .sdata or .sbss section.
Support is indicated in the target options via the
small-data-threshold-support target option, which can indicate either an
LLVM argument or an LLVM module flag. To avoid duplicate specifications
in a large number of targets, the default value for support is
DefaultForArch, which is translated to a concrete value according to the
target's architecture.
When linking macOS targets with cc, pass the `-mmacosx-version-min=.`
option to specify the desired deployment target. Also, no longer pass
`-m32`/`-m64`, these are redundant since we already pass `-arch`.
When linking with cc on other Apple targets, always pass `-target`.
(We assume for these targets that cc => clang).
The minimum that `rustc` encoded did not match the version in Clang, and
that meant that that when linking, we ended up bumping the version.
Specifically, this sets the correct deployment target of the following
simulator and Mac Catalyst targets:
- `aarch64-apple-ios-sim` from 10.0 to 14.0
- `aarch64-apple-tvos-sim` from 10.0 to 14.0
- `aarch64-apple-watchos-sim` from 5.0 to 7.0
- `aarch64-apple-ios-macabi` from 13.1 to 14.0
I have chosen to not document the simulator target versions in the
platform support docs, as it is fundamentally uninteresting; the normal
targets (e.g. `aarch64-apple-ios`, `aarch64-apple-tvos`) still have the
same deployment target as before, and that's what developers should
actually target.
Apple: Refactor deployment target version parsing
Refactor deployment target parsing to make it easier to do https://github.com/rust-lang/rust/pull/129342 (I wanted to make sure of all the places that `std::env::var` is called).
Specifically, my goal was to minimize the amount of target-specific configuration, so to that end I renamed the `opts` function that generates the `TargetOptions` to `base`, and made it return the LLVM target and `target_arch` too. In the future, I would like to move even more out of the target files and into `spec::apple`, as it makes it easier for me to maintain.
For example, this fixed a bug in `aarch64-apple-watchos`, which wasn't passing the deployment target as part of the LLVM triple. This (probably) fixes https://github.com/rust-lang/rust/issues/123582 and fixes https://github.com/rust-lang/rust/issues/107630.
We also now parse the patch version of deployment targets, allowing the user to specify e.g. `MACOSX_DEPLOYMENT_TARGET=10.12.6`.
Finally, this fixes the LLVM target name for visionOS, it should be `*-apple-xros` and not `*-apple-visionos`.
Since I have changed all the Apple targets here, I smoke-tested my changes by running the following:
```console
# Build each target
./x build library --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,arm64e-apple-ios,armv7k-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
# Test that we can still at least link basic projects
cargo new foobar && cd foobar && cargo +stage1 build --target=aarch64-apple-darwin --target=aarch64-apple-ios --target=aarch64-apple-ios-macabi --target=aarch64-apple-ios-sim --target=aarch64-apple-tvos --target=aarch64-apple-tvos-sim --target=aarch64-apple-visionos --target=aarch64-apple-visionos-sim --target=aarch64-apple-watchos --target=aarch64-apple-watchos-sim --target=arm64_32-apple-watchos --target=armv7s-apple-ios --target=i386-apple-ios --target=x86_64-apple-darwin --target=x86_64-apple-ios --target=x86_64-apple-ios-macabi --target=x86_64-apple-tvos --target=x86_64-apple-watchos-sim --target=x86_64h-apple-darwin
```
I couldn't build for the `arm64e-apple-darwin` target, the `armv7k-apple-watchos` and `arm64e-apple-ios` targets failed to link, and I know that the `i686-apple-darwin` target requires a bit of setup, but all of this is as it was before this PR.
r? thomcc
CC `@BlackHoleFox`
I would recommend using `rollup=never` when merging this, in case we need to bisect this later.
- Merge minimum OS version list into one function (makes it easier to
see the logic in it).
- Parse patch deployment target versions.
- Consistently specify deployment target in LLVM target (previously
omitted on `aarch64-apple-watchos`).
Add target support for RTEMS Arm
# `armv7-rtems-eabihf`
This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (https://github.com/rust-lang/libc/pull/3561) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.
Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.
> 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.
There should be no breaking changes for existing targets. Main changes are adding corresponding `cfg` switches for the RTEMS OS and adding the C binding in libc.
# Tier 3 target policy
> - 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.)
I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.
> - 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.
The proposed triple is `armv7-rtems-eabihf`
> - 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.
The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.
> - 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.
N/A to me. I am not a reviewer nor Rust team member.
> - 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.
`core` and `std` compile. Some advanced features of the `std` lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.
> - 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.
Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.
> - 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.
Understood.
> - 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.
Ok
> - 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.
I think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).
> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
Can produce assembly code via the llvm backend (tested on Linux).
>
> 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.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.
Understood.
r? compiler-team
update comment regarding TargetOptions.features
The claim that `-Ctarget-features` cannot disable these features set in the target spec is definitely wrong -- I tried it for `x86_64-pc-windows-gnu`, which enables SSE3 that way. Building with `-Ctarget-feature=-sse3` works fine, and `cfg!(target_feature = "sse3")` is `false` in that build.
There are also some indications that these are actually intended to be overwritten:
3b14526cea/compiler/rustc_target/src/spec/targets/i686_unknown_uefi.rs (L22-L23)84ac80f192/compiler/rustc_target/src/spec/targets/x86_64h_apple_darwin.rs (L18-L23)
So... let's update the comment to match reality, I guess?
The claim that they overwrite `-Ctarget-cpu` is based on
- for `native`, the comment in the apple target spec quoted above
- for other CPU strings, the assumption that `LLVMRustCreateTargetMachine` will apply these features after doing whatever the base CPU model does. I am not sure how to check that, I hope some LLVM backend people can chime in. :)
Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf
This patch fix https://github.com/rust-lang/rust/issues/129825
For the riscv64imac target, the LLVM ABI NAME should be "lp64", which is the default ABI if not specified for the riscv64imac target.
add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le
This backports the QNX 7.1 aarch64 implementation to 7.0.
* [x] required `-lregex` disabled, see https://github.com/rust-lang/libc/pull/3775 (released in libc 0.2.156)
* [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s)
* [x] a fix in `backtrace` crate to support stack traces https://github.com/rust-lang/backtrace-rs/pull/648
This PR bumps libc dependency to 0.2.158
CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric`
# Compile target
```bash
# Configure qcc build environment
source _path_/_to_/qnx7.0/qnxsdp-env.sh
# Tell rust to use qcc when building QNX 7.0 targets
export build_env='
CC_aarch64-unknown-nto-qnx700=qcc
CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx
CXX_aarch64-unknown-nto-qnx700=qcc
AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar'
# Build rust compiler, libs, and the remote test server
env $build_env ./x.py build \
--target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \
rustc library/core library/alloc library/std src/tools/remote-test-server
rustup toolchain link stage1 build/host/stage1
```
# Compile "hello world"
```bash
source _path_/_to_/qnx7.0/qnxsdp-env.sh
cargo new hello_world
cd hello_world
cargo +stage1 build --release --target aarch64-unknown-nto-qnx700
```
# Configure a remote for testing
Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds.
* Temporary dir might not work properly
* Default `remote-test-server` has issues binding to an address
```
# ./remote-test-server
starting test server
thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29:
called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly.
```bash
# Copy remote-test-server to remote device. You may need to use sftp instead.
# ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason
scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/
# Run ssh with port forwarding - so that rust tester can connect to the local port instead
ssh -L 12345:127.0.0.1:12345 qnxdevice
# on the device, run
rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345
```
# Run test suit
Assume all previous environment variables are still set, or re-init them
```bash
export TEST_DEVICE_ADDR="localhost:12345"
# tidy needs to be skipped due to using un-published libc dependency
export exclude_tests='
--exclude src/bootstrap
--exclude src/tools/error_index_generator
--exclude src/tools/linkchecker
--exclude src/tools/tidy
--exclude tests/ui-fulldeps
--exclude rustc
--exclude rustdoc
--exclude tests/run-make-fulldeps'
env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700
```
try-job: dist-x86_64-msvc
This patch fix https://github.com/rust-lang/rust/issues/129825
For the riscv64imac target, the LLVM ABI NAME should be "lp64",
which is the default ABI if not specified for the riscv64imac target.
Correct trusty targets to be tier 3
The Trusty targets were added in https://github.com/rust-lang/rust/pull/129490, but in that PR I accidentally marked them as tier 2. This PR corrects the target metadata to mark them as tier 3.
rustc_target: Add various aarch64 features
Add various aarch64 features already supported by LLVM and Linux.
Additionally include some comment fixes to ensure consistency of feature names with the Arm ARM.
Compiler support for features added to stdarch by https://github.com/rust-lang/stdarch/pull/1614.
Tracking issue for unstable aarch64 features is https://github.com/rust-lang/rust/issues/127764.
List of added features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_HBC
- FEAT_LSE128
- FEAT_LSE2
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
- FEAT_SME
- FEAT_SME_F16F16
- FEAT_SME_F64F64
- FEAT_SME_F8F16
- FEAT_SME_F8F32
- FEAT_SME_FA64
- FEAT_SME_I16I64
- FEAT_SME_LUTv2
- FEAT_SME2
- FEAT_SME2p1
- FEAT_SSVE_FP8DOT2
- FEAT_SSVE_FP8DOT4
- FEAT_SSVE_FP8FMA
FEAT_FPMR is added in the first commit and then removed in a separate one to highlight it being removed from upstream LLVM 19. The intention is for it to be detectable at runtime through stdarch but not have a corresponding Rust compile-time feature.
FEAT_FPMR has been removed from upstream LLVM as of LLVM 19.
Remove the feature from the target features list and temporarily hack
the LLVM codegen to always enable it until the minimum LLVM version is
bumped to 19.
Add SME aarch64 features already supported by LLVM and Linux.
This commit adds compiler support for the following features:
- FEAT_SME
- FEAT_SME_F16F16
- FEAT_SME_F64F64
- FEAT_SME_F8F16
- FEAT_SME_F8F32
- FEAT_SME_FA64
- FEAT_SME_I16I64
- FEAT_SME_LUTv2
- FEAT_SME2
- FEAT_SME2p1
- FEAT_SSVE_FP8DOT2
- FEAT_SSVE_FP8DOT4
- FEAT_SSVE_FP8FMA
Add various aarch64 features already supported by LLVM and Linux.
The features are marked as unstable using a newly added symbol, i.e.
aarch64_unstable_target_feature.
Additionally include some comment fixes to ensure consistency of
feature names with the Arm ARM and support for architecture version
target features up to v9.5a.
This commit adds compiler support for the following features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_FPMR
- FEAT_HBC
- FEAT_LSE128
- FEAT_LSE2
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
Add `f16` and `f128` inline ASM support for `aarch64`
Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in #127043.
Relevant issue: #125398
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
try-job: aarch64-gnu
try-job: aarch64-apple
Move ZST ABI handling to `rustc_target`
Currently, target specific handling of ZST function call ABI (specifically passing them indirectly instead of ignoring them) is handled in `rustc_ty_utils`, whereas all other target specific function call ABI handling is located in `rustc_target`. This PR moves the ZST handling to `rustc_target` so that all the target-specific function call ABI handling is in one place. In the process of doing so, this PR fixes#125850 by ensuring that ZST arguments are always correctly ignored in the x86-64 `"sysv64"` ABI; any code which would be affected by this fix would have ICEd before this PR. Tests are also added using `#[rustc_abi(debug)]` to ensure this behaviour does not regress.
Fixes#125850
Promote Mac Catalyst targets to Tier 2, and ship with rustup
Promote the Mac Catalyst targets `x86_64-apple-ios-macabi` and `aarch64-apple-ios-macabi` to Tier 2, as per [the MCP](https://github.com/rust-lang/compiler-team/issues/761) (see that for motivation and details).
These targets are now also distributed with rustup, although without the sanitizer runtime, as that currently has trouble building, see https://github.com/rust-lang/rust/issues/129069.
Add powerpc-unknown-linux-muslspe compile target
This is almost identical to already existing targets:
- powerpc_unknown_linux_musl.rs
- powerpc_unknown_linux_gnuspe.rs
It has support for PowerPC SPE (muslspe), which
can be used with GCC version up to 8. It is useful for Freescale or IBM cores like e500.
This was verified to be working with OpenWrt build system for CZ.NIC's Turris 1.x routers, which are using Freescale P2020, e500v2, so add it as a Tier 3 target.
Follow-up of https://github.com/rust-lang/rust/pull/100860
Refactor `powerpc64` call ABI handling
As the [specification](https://openpowerfoundation.org/specifications/64bitelfabi/) for the ELFv2 ABI states that returned aggregates are returned like arguments as long as they are at most two doublewords, I've merged the `classify_arg` and `classify_ret` functions to reduce code duplication. The only functional change is to fix#128579: the `classify_ret` function was incorrectly handling aggregates where `bits > 64 && bits < 128`. I've used the aggregate handling implementation from `classify_arg` which doesn't have this issue.
`@awilfox` could you test this on `powerpc64-unknown-linux-musl`? I'm only able to cross-test on `powerpc64-unknown-linux-gnu` and `powerpc64le-unknown-linux-gnu` locally at the moment, and as a tier 3 target `powerpc64-unknown-linux-musl` has zero CI coverage.
Fixes: #128579
Use more slice patterns inside the compiler
Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.
r? ghost
Promote aarch64-apple-darwin to Tier 1
This promotes aarch64-apple-darwin to Tier 1 status as per rust-lang/rfcs#3671 and tracking issue #73908. Not sure what else is necessary for this to impement the aforementioned RFC, however I figured I'd try. I did read in previous issues and PRs that the necessary infrastructure was already in place for the aarch64-apple-darwin target, and the RFC mentions the same. So this should be all thats necessary in order for the target to be promoted.
This is a recreation of my previous PR because I accidentally did an incorrect git rebase which caused unnecessary changes to various commit SHAs. So this PR is a recreation of my previous PR without said stumble. My bad.
Update compiler_builtins to 0.1.114
The `weak-intrinsics` feature was removed from compiler_builtins in https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the `compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.
In https://github.com/rust-lang/compiler-builtins/pull/593, some builtins for f16/f128 were added. These don't work for all compiler backends, so add a `compiler-builtins-no-f16-f128` feature and disable it for cranelift and gcc.
Add NuttX based targets for RISC-V and ARM
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. It is scalable from 8-bit to 64-bit microcontroller environments. The primary governing standards in NuttX are POSIX and ANSI standards.
NuttX adopts additional standard APIs from Unix and other common RTOSs, such as VxWorks. These APIs are used for functionality not available under the POSIX and ANSI standards. However, some APIs, like fork(), are not appropriate for deeply-embedded environments and are not implemented in NuttX.
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
I'll be adding libstd support for NuttX in the future, but for now I'll just add the targets.
Tier 3 policy:
> 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.)
I will be the target maintainer for this target on matters that pertain to the NuttX part of the triple. For matters pertaining to the riscv or arm part of the triple, there should be no difference from all other targets. If there are issues, I will address issues regarding the target.
> 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.
This is a new supported OS, so I have taken the origin target like `riscv32imac-unknown-none-elf` or `thumbv7m-none-eabi` and changed the `os` section to `nuttx`.
> 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.
I feel that the target name does not introduce any ambiguity.
> 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 only unusual requirement for building the compiler-builtins crate is a standard RISC-V or ARM C compiler supported by cc-rs, and using this target does not require any additional software beyond what is shipped by rustup.
> The target must not introduce license incompatibilities.
All of the additional code will use Apache-2.0.
> Anything added to the Rust repository must be under the standard Rust
> license (`MIT OR Apache-2.0`).
Agreed, and there is no problem here.
> 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.
No new dependencies are added.
> 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.
Linking is performed by rust-lld
> "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.
There are no terms. NuttX is distributed under the Apache 2.0 license.
> 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.
I'm not the reviewer here.
> 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.
Again I'm not the reviewer here.
> 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.
> 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.
Building is described in platform support doc, but libstd is not supported now, I'll implement it later.
> 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.
Understood.
> 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.
I believe I didn't break any other 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.
I think there are no such problems in this PR.
> 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.)
Yes, it use standard RISCV or ARM backend to generate assembly.
rustc_target: add known safe s390x target features
This pull request adds known safe target features for s390x (aka IBM Z systems).
Currently, these features are unstable since stabilizing the target features requires submitting proposals.
The `vector` feature was added in IBM Z13 (`arch11`), and this is a SIMD feature for the newer IBM Z systems.
The `backchain` attribute is the IBM Z way of adding frame pointers like unwinding capabilities (the "frame-pointer" switch on IBM Z and IBM POWER platforms will add _emulated_ frame pointers to the binary, which profilers can't use for unwinding the stack).
Both attributes can be applied at the LLVM module or function levels. However, the `backchain` attribute has to be enabled for all the functions in the call stack to get a successful unwind process.
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. It is scalable from 8-bit to 64-bit microcontroller environments. The primary governing standards in NuttX are POSIX and ANSI standards.
NuttX adopts additional standard APIs from Unix and other common RTOSs, such as VxWorks. These APIs are used for functionality not available under the POSIX and ANSI standards. However, some APIs, like fork(), are not appropriate for deeply-embedded environments and are not implemented in NuttX.
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
I'll be adding libstd support for NuttX in the future, but for now I'll just add the targets.
Tier 3 policy:
> 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.)
I will be the target maintainer for this target on matters that pertain to the NuttX part of the triple.
For matters pertaining to the riscv or arm part of the triple, there should be no difference from all other targets. If there are issues, I will address issues regarding the target.
> 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.
This is a new supported OS, so I have taken the origin target like `riscv32imac-unknown-none-elf` or `thumbv7m-none-eabi`
and changed the `os` section to `nuttx`.
> 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.
I feel that the target name does not introduce any ambiguity.
> 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 only unusual requirement for building the compiler-builtins crate is a standard RISC-V or ARM C compiler supported by cc-rs, and using this target does not require any additional software beyond what is shipped by rustup.
> The target must not introduce license incompatibilities.
All of the additional code will use Apache-2.0.
> Anything added to the Rust repository must be under the standard Rust
> license (`MIT OR Apache-2.0`).
Agreed, and there is no problem here.
> 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.
No new dependencies are added.
> 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.
Linking is performed by rust-lld
> "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.
There are no terms. NuttX is distributed under the Apache 2.0 license.
> 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.
I'm not the reviewer here.
> 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.
Again I'm not the reviewer here.
> 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.
> 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.
Building is described in platform support doc, but libstd is not supported now,
I'll implement it later.
> 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.
Understood.
> 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.
I believe I didn't break any other 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.
I think there are no such problems in this PR.
> 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.)
Yes, it use standard RISCV or ARM backend to generate assembly.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
This is almost identical to already existing targets:
- powerpc_unknown_linux_musl.rs
- powerpc_unknown_linux_gnuspe.rs
It has support for PowerPC SPE (muslspe), which
can be used with GCC version up to 8. It is useful for Freescale or IBM
cores like e500.
This was verified to be working with OpenWrt build system for CZ.NIC's
Turris 1.x routers, which are using Freescale P2020, e500v2, so add it as
a Tier 3 target.
In llvm/llvm-project@f0eb5587ce all
support for 3DNow! intrinsics and instructions were removed. Per the commit message
there, only AMD chips between 1998 and 2011 or so actually supported
these instructions, and they were effectively replaced by SSE which was
available on many more chips. I'd be very surprised if anyone had ever
used these from Rust.
... this is a special attribute that was made to be a target-feature in
LLVM 18+, but in all previous versions, this "feature" is a naked
attribute. We will have to handle this situation differently than all
other target-features.
Fill out target-spec metadata for all targets
**What does this PR try to resolve?**
This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](https://github.com/rust-lang/wg-cargo-std-aware/issues/87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`.
**How should we test and review this PR?**
Check that a given target-spec metadata has been updated with:
```
$ ./x.py build library/std
$ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options
```
**Additional Information**
A few things to note:
* Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build
* There's no rush for this to be merged. I understand that the format for this is not finalised yet.
* Related: #120745
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked
in #83788).
As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679
and following, this ABI is a failed experiment that did not end
up being used for anything. Keeping support for this ABI in LLVM 19
would require us to switch wasm targets to the `experimental-mv`
ABI, which we do not want to do.
It should be noted that `Abi::Wasm` was internally used for two
things: The `-Z wasm-c-abi=legacy` ABI that is still used by
default on some wasm targets, and the `extern "wasm"` ABI. Despite
both being `Abi::Wasm` internally, they were not the same. An
explicit `extern "wasm"` additionally enabled the `+multivalue`
feature.
I've opted to remove `Abi::Wasm` in this patch entirely, instead
of keeping it as an ABI with only internal usage. Both
`-Z wasm-c-abi` variants are now treated as part of the normal
C ABI, just with different different treatment in
adjust_for_foreign_abi.
Fix 32-bit Arm reg classes by hierarchically sorting them
We were rejecting legal `asm!` because we were asking for the "greatest" feature that includes a register class, instead of the "least" feature that includes a register class. This was only revealed on certain 32-bit Arm targets because not all have the same register limitations.
This is a somewhat hacky solution, but other solutions would require potentially rearchitecting how the internals of parsing or rejecting register classes work for all targets.
Fixes#126797
r? ``@Amanieu``
Add `f16` inline ASM support for 32-bit ARM
Adds `f16` inline ASM support for 32-bit ARM. SIMD vector types are taken from [here](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A32]).`
Relevant issue: #125398
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
Add `f16` inline ASM support for RISC-V
This PR adds `f16` inline ASM support for RISC-V. A `FIXME` is left for `f128` support as LLVM does not support the required `Q` (Quad-Precision Floating-Point) extension yet.
Relevant issue: #125398
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
Expand `avx512_target_feature` to include VEX variants
Added 5 new target features for x86:
- `AVX-IFMA`
- `AVX-NE-CONVERT`
- `AVX-VNNI`
- `AVX-VNNI_INT8`
- `AVX-VNNI_INT16`
Both LLVM and GCC already have support for these.
See also the [stdarch PR](https://github.com/rust-lang/stdarch/pull/1586)
Clean up some comments near `use` declarations
#125443 will reformat all `use` declarations in the repository. There are a few edge cases involving comments on `use` declarations that require care. This PR cleans up some clumsy comment cases, taking us a step closer to #125443 being able to merge.
r? ``@lqd``
Add std Xtensa targets support
Adds std Xtensa targets. This enables using Rust on ESP32, ESP32-S2 and ESP32-S3 chips.
Tier 3 policy:
> 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.)
`@MabezDev,` `@ivmarkov` and I (`@SergioGasquez)` will maintain the targets.
> 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.
The target triple is consistent with other targets.
> 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.
We follow the same naming convention as other targets.
> 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 does not introduce any legal issues.
> The target must not introduce license incompatibilities.
There are no license incompatibilities
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Everything added is under that licenses
> 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.
Requirements are not changed for any other target.
> 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.
The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for Xtensa.
GNU GPL.
> "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.
No such terms exist for this target
> 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.
The targets implement libStd almost in its entirety, except for the missing support for process, as
this is a bare metal platform. The process `sys\unix` module is currently stubbed to return "not
implemented" errors.
> 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.
Here is how to build for the target https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html
and it also covers how to run binaries on the target.
> 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.
No other targets should be affected
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends
from any host target.
It can produce assembly, but it requires a custom LLVM with Xtensa support
(https://github.com/espressif/llvm-project/). The patches are trying to be upstreamed
(https://github.com/espressif/llvm-project/issues/4)
This makes their intent and expected location clearer. We see some
examples where these comments were not clearly separate from `use`
declarations, which made it hard to understand what the comment is
describing.
Add `target_env = "p1"` to the `wasm32-wasip1` target
This commit sets the `target_env` key for the
`wasm32-wasi{,p1,p1-threads}` targets to the string `"p1"`. This mirrors how the `wasm32-wasip2` target has `target_env = "p2"`. The intention of this is to more easily detect each target in downstream crates to enable adding custom code per-target.
cc #125803
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Add no_std Xtensa targets support
Adds no_std Xtensa targets. This enables using Rust on ESP32, ESP32-S2 and ESP32-S3 chips.
Tier 3 policy:
> 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.)
`@MabezDev` and I (`@SergioGasquez)` will maintain the targets.
> 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.
The target triple is consistent with other targets.
> 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.
We follow the same naming convention as other targets.
> 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 does not introduce any legal issues.
> The target must not introduce license incompatibilities.
There are no license incompatibilities
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Everything added is under that licenses
> 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.
Requirements are not changed for any other target.
> 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.
The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for Xtensa. GNU GPL.
> "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.
No such terms exist for this target
> 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.
The target already implements core.
> 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.
Here is how to build for the target https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html and it also covers how to run binaries on the target.
> 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.
No other targets should be affected
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
It can produce assembly, but it requires a custom LLVM with Xtensa support (https://github.com/espressif/llvm-project/). The patches are trying to be upstreamed (https://github.com/espressif/llvm-project/issues/4)
Nvptx remove direct passmode
This PR does what should have been done in #117671. That is fully avoid using the `PassMode::Direct` for `extern "C" fn` for `nvptx64-nvidia-cuda` and enable the compatibility test. `@RalfJung` [pointed me in the right direction](https://github.com/rust-lang/rust/issues/117480#issuecomment-2137712501) for solving this issue.
There are still some ABI bugs after this PR is merged. These ABI tests are created based on what is actually correct, and since they continue passing with even more of them enabled things are improving. I don't have the time to tackle all the remaining issues right now, but I think getting these improvements merged is very valuable in themselves and plan to tackle more of them long term.
This also doesn't remove the use of `PassMode::Direct` for `extern "ptx-kernel" fn`. This was also not trivial to make work. And since the ABI is hidden behind an unstable feature it's less urgent.
I don't know if it's correct to request `@RalfJung` as a reviewer (due to team structures), but he helped me a lot to figure out this stuff. If that's not appropriate then `@davidtwco` would be a good candidate since he know about this topic from #117671
r? `@RalfJung`
This commit sets the `target_env` key for the
`wasm32-wasi{,p1,p1-threads}` targets to the string `"p1"`. This mirrors
how the `wasm32-wasip2` target has `target_env = "p2"`. The intention of
this is to more easily detect each target in downstream crates to enable
adding custom code per-target.
cc #125803
NVPTX: Avoid PassMode::Direct for args in C abi
Fixes#117480
I must admit that I'm confused about `PassMode` altogether, is there a good sum-up threads for this anywhere? I'm especially confused about how "indirect" and "byval" goes together. To me it seems like "indirect" basically means "use a indirection through a pointer", while "byval" basically means "do not use indirection through a pointer".
The return used to keep `PassMode::Direct` for small aggregates. It turns out that `make_indirect` messes up the tests and one way to fix it is to keep `PassMode::Direct` for all aggregates. I have mostly seen this PassMode mentioned for args. Is it also a problem for returns? When experimenting with `byval` as an alternative i ran into [this assert](61a3eea804/compiler/rustc_codegen_llvm/src/abi.rs (L463C22-L463C22))
I have added tests for the same kind of types that is already tested for the "ptx-kernel" abi. The tests cannot be enabled until something like #117458 is completed and merged.
CC: ``@RalfJung`` since you seem to be the expert on this and have already helped me out tremendously
CC: ``@RDambrosio016`` in case this influence your work on `rustc_codegen_nvvm`
``@rustbot`` label +O-NVPTX
Relax restrictions on multiple sanitizers
Most combinations of LLVM sanitizers are legal-enough to enable simultaneously. This change will allow simultaneously enabling ASAN and shadow call stacks on supported platforms.
I used this python script to generate the mutually-exclusive sanitizer combinations:
```python
#!/usr/bin/python3
import subprocess
flags = [
["-fsanitize=address"],
["-fsanitize=leak"],
["-fsanitize=memory"],
["-fsanitize=thread"],
["-fsanitize=hwaddress"],
["-fsanitize=cfi", "-flto", "-fvisibility=hidden"],
["-fsanitize=memtag", "--target=aarch64-linux-android", "-march=armv8a+memtag"],
["-fsanitize=shadow-call-stack"],
["-fsanitize=kcfi", "-flto", "-fvisibility=hidden"],
["-fsanitize=kernel-address"],
["-fsanitize=safe-stack"],
["-fsanitize=dataflow"],
]
for i in range(len(flags)):
for j in range(i):
command = ["clang++"] + flags[i] + flags[j] + ["-o", "main.o", "-c", "main.cpp"]
completed = subprocess.run(command, stderr=subprocess.DEVNULL)
if completed.returncode != 0:
first = flags[i][0][11:].replace('-', '').upper()
second = flags[j][0][11:].replace('-', '').upper()
print(f"(SanitizerSet::{first}, SanitizerSet::{second}),")
```
Refactor documentation for Apple targets
Refactor the documentation for Apple targets in `rustc`'s platform support page to make it clear what the supported OS version is and which environment variables are being read (`*_DEPLOYMENT_TARGET` and `SDKROOT`). This fixes https://github.com/rust-lang/rust/issues/124215.
Note that I've expanded the `aarch64-apple-ios-sim` maintainers `@badboy` and `@deg4uss3r` to include being maintainer of all `*-apple-ios-*` targets. If you do not wish to be so, please state that, then I'll explicitly note that in the docs.
Additionally, I've added myself as co-maintainer of most of these targets.
r? `@thomcc`
I think the documentation you've previously written on tvOS is great, have mostly modified it to have a more consistent formatting with the rest of the Apple target.
I recognize that there's quite a few changes here, feel free to ask about any of them!
---
CC `@simlay` `@Nilstrieb`
`@rustbot` label O-apple
the `rust.lld` config enables rustc's `CFG_USE_SELF_CONTAINED_LINKER` env var, and we:
- set the linker-flavor to use lld
- enable the self-contained linker
this makes the target use the rust-lld linker by default
Most combinations of LLVM sanitizers are legal-enough to enable
simultaneously. This change will allow simultaneously enabling ASAN and
shadow call stacks on supported platforms.
Refactor Apple `target_abi`
This was bundled together with `Arch`, which complicated a few code paths and meant we had to do more string matching than necessary.
CC `@BlackHoleFox` as you've worked on the Apple target spec before
Related: Is there a reason why `Target`/`TargetOptions` use `StaticCow` for so many things, instead of an enum with defined values (and perhaps a catch-all case for custom target json files)? Tagging `@Nilstrieb,` as you might know?
Add `-lmingwex` second time in `mingw_libs`
Upcoming mingw-w64 releases will contain small math functions refactor which moved implementation around. As a result functions like `lgamma`
now depend on libraries in this order:
`libmingwex.a` -> `libmsvcrt.a` -> `libmingwex.a`.
Fixes#124221
Refactor float `Primitive`s to a separate `Float` type
Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`.
As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`.
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
rustc: Some small changes for the wasm32-wasip2 target
This commit has a few changes for the wasm32-wasip2 target. The first two are aimed at improving the compatibility of using `clang` as an external linker driver on this target. The default target to LLVM is updated to match the Rust target and additionally the `-fuse-ld=lld` argument is dropped since that otherwise interferes with clang's own linker detection. The only linker on wasm targets is LLD but on the wasip2 target a wrapper around LLD, `wasm-component-ld`, is used to drive the process and perform steps necessary for componentization.
The final commit changes the output of all objects on the wasip2 target to being PIC by default. This improves compatibilty with shared libaries but notably does not mean that there's a turnkey solution for shared libraries. The hope is that by having the standard libray work both with and without dynamic libraries will make experimentation easier.
This commit changes the new `wasm32-wasip2` target to being PIC by
default rather than the previous non-PIC by default. This change is
intended to make it easier for the standard library to be used in a
shared object in its precompiled form. This comes with a hypothetical
modest slowdown but it's expected that this is quite minor in most use
cases or otherwise wasm compilers and/or optimizing runtimes can elide
the cost.
LLVM has updated data layouts to specify `Fn32` on 64-bit ARM to avoid
C++ accidentally underaligning functions when trying to comply with
member function ABIs.
This should only affect Rust in cases where we had a similar bug (I
don't believe we have one), but our data layout must match to generate
code.
As a compatibility adaptatation, if LLVM is not version 19 yet, `Fn32`
gets voided from the data layout.
See llvm/llvm-project#90415
- Fixed std support in top-level docs.
- Added `*-apple-darwin` docs.
- Added `i686-apple-darwin` docs.
- Moved `aarch64-apple-ios-sim` to `*-apple-ios` and document all the
iOS targets there.
- Added `*-apple-ios-macabi` docs.
- Add myself (madsmtm) as co-maintainer of most of these targets.
Set non-leaf frame pointers on Fuchsia targets
This is part of our work to enable shadow call stack sanitization on Fuchsia, see [this Fuchsia issue](https://g-issues.fuchsia.dev/issues/327643884).
r? ``@tmandry``
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
This commit changes the LLVM target of for the Rust `wasm32-wasip2`
target to `wasm32-wasip2` as well. LLVM does a bit of detection on the
target string to know when to call `wasm-component-ld` vs `wasm-ld` so
otherwise clang is invoking the wrong linker.
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
Upcoming mingw-w64 releases will contain small math functions refactor which moved implementation around.
As a result functions like `lgamma`
now depend on libraries in this order:
`libmingwex.a` -> `libmsvcrt.a` -> `libmingwex.a`.
Fixes#124221
Introduce perma-unstable `wasm-c-abi` flag
Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.
This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.
Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.
This is a companion PR to #117918, but they could be merged independently.
MCP: https://github.com/rust-lang/compiler-team/issues/703
Tracking issue: https://github.com/rust-lang/rust/issues/122532
