Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`
followup on rust-lang/rust#150766
add an `s390x-unknown-none-softfloat` target to use for kernel compilation, as the Linux kernel does not wish to pay the overhead of saving float registers by default on kernel switch. this target's `extern "C"` ABI is unspecified, so it is unstable and subject to change between versions, just like the Linux intrakernel ABI and `extern "Rust"` ABIs are unstable.
enforce target feature incompatibility by adding `RustcAbi::Softfloat`. this is itself just a rename of `RustcAbi::X86Softfloat`, accepting both "x86-softfloat" and "softfloat" as valid strings in the target.json format. the target-features of `"soft-float"` and `"vector"` are incompatible for s390x, so issue a compatibility warning if they are combined.
This target is intended to be used for kernel development. Becasue on s390x
float and vector registers overlap we have to disable the vector extension.
The default s390x-unknown-gnu-linux target will not allow use of
softfloat.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
bootstrap: always propagate `CARGO_TARGET_{host}_LINKER`
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
Convert to inline diagnostics in `rustc_lint`
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
This was a big one! Second to last one, `rustc_parse` is the last one and even bigger :P
Use relative paths for std links in rustc-docs
Fixesrust-lang/rust#151496
This adds `--extern-html-root-url` for each `STD_PUBLIC_CRATES` entry pointing to `../`, so that `rustc-docs` links to the locally installed `rust-docs` via relative paths.
r? @GuillaumeGomez @rami3l
bootstrap: Remove `ShouldRun::paths`
Split out from https://github.com/rust-lang/rust/pull/151930. I've copied my comment in https://github.com/rust-lang/rust/pull/151930#discussion_r2750409129 into the commit description.
r? @Zalathar cc @Mark-Simulacrum @Kobzol
---
Some history about `paths()`. The original intent @Mark-Simulacrum had
when he introduced PathSet in https://github.com/rust-lang/rust/commit/f104b120595d21e8aef311bc0057b3f854cddfc0, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in rust-lang/rust#95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Some history about `paths()`. The original intent Mark-Simulacrum had
when he introduced PathSet, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in 95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Co-authored-by: Tshepang Mbambo <hopsi@tuta.io>
update openmp/offload builds to LLVM 22, Part 1
This part of the update of OpenMP/Offload to LLVM 22 does not depend on a backport in the future LLVM release candidate 3. Let's therefore merge it first, to unblock existing users/developers.
r? @jieyouxu
Hexagon Linux targets (hexagon-unknown-linux-musl) use in-tree
llvm-libunwind for stack unwinding. However, hexagon-unknown-qurt
uses libc_eh from the Hexagon SDK instead.
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
Introducing clap on tidy
### Context
Currently tidy parses paths/flags from args_os manually, and the extraction is spreading multiple files. It may be a breeding ground for bugs.
ref: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/How.20--ci.3Dtrue.20interact.20with.20CiEnv.3F/near/543171560
(N.B. We've talked about introducing a ci flag in tidy in that thread, but I don't do it in this PR as I don't want to put multiple changes into a PR. I will introduce the flag in a coming PR.)
### Changes
This PR replaces current parsing logic with clap. To confirm the new parser works fine, I introduce an unit test for it.
### Build time
We've concerned about how clap increases the build time. In order to confirm the increment is acceptable, I did an experiment on CI:
- Run cargo build without cache for tidy 50 times in each environment on CI
- Calculate an average and a standard deviation from the result, and plot them
Here is the graph:
<img width="943" height="530" alt="rust_tidy_build_time" src="https://github.com/user-attachments/assets/c7deee69-9f38-4044-87dc-76d6e7384f76" />
- Clap tends to increase build time ~2s. We think this is not a big problem
- Build time differs in each environment
- In some cases standard deviation are high, I suppose that busyness of CI instances affect build time
Currently some required arguments (like path of the root dir) are ordered, but it causes an user (mainly bootstrap) needs to remember the order. This commit introduces long arguments (e.g., --root-path) for required args.
Rustc no longer depends on winapi. Only cg_clif, cg_gcc and rustfmt
still use it, none of which are libraries to compile against. And in
case of both cg_clif and cg_gcc it never ends up in an artifact we ship.
For cg_clif it only shows up when the jit mode is enabled, which is not
the case for the version we ship. For cg_gcc it is used by a test
executable, which isn't shipped either.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
Various refactors to the proc_macro bridge
This reduces the amount of types, traits and other abstractions that are involved with the bridge, which should make it easier to understand and modify. This should also help a bit with getting rid of the type marking hack, which is complicating the code a fair bit.
Fixes: rust-lang/rust#139810
Add Korean translation to Rust By Example
Hello,
I’ve added a Korean translation file to Rust By Example.
This contribution will help Korean readers learn Rust more easily by providing localized explanations and examples.
Please review the proposed additions when you have time.
Thanks in advance for your time and review! 🙏
Add Korean translation. Thanks in advance.
Add new Tier 3 targets for ARMv6
Adds three new targets to support ARMv6 processors running bare-metal:
* `armv6-none-eabi` - Arm ISA, soft-float
* `armv6-none-eabihf` - Arm ISA, hard-float
* `thumbv6-none-eabi` - Thumb-1 ISA, soft-float
There is no `thumbv6-none-eabihf` target because as far as I can tell, hard-float isn't support with the Thumb-1 instruction set (and you need the ARMv6T2 extension to enable Thumb-2 support).
The targets require ARMv6K as a minimum, which allows the two Arm ISA targets to have full CAS atomics. LLVM has a bug which means it emits some ARMv6K instructions even if you only call for ARMv6, and as no-one else has noticed the bug, and because basically all ARMv6 processors have ARMv6K, I think this is fine. The Thumb target also doesn't have any kind of atomics, just like the Armv5TE and Armv4 targets, because LLVM was emitting library calls to emulate them.
Testing will be added to https://github.com/rust-embedded/aarch32 once the target is accepted. I already have tests for the other non-M arm-none-eabi targets, and those tests pass on these targets.
> 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 have listed myself. If accepted, I'll talk to the Embedded Devices Working Group about adding this one to the rosta with all the others they support.
> 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.
You might prefer `arm-none-eabi`, because `arm-unknown-linux-gnu` is an ARMv6 target - the implicit rule seems to be that if the Arm architecture version isn't specified, it's assumed to be v6. However, `armv6-none-eabi` seemed to fit better between `armv5te-none-eabi` and `armv7a/armv7r-none-eabi`.
The hamming distance between `thumbv6-none-eabi` and `thumbv6m-none-eabi` is unfortunately low, but I don't know how to make it better. They *are* the ARMv6 and ARMv6-M targets, and its perhaps not worse than `armv7a-none-eabi` and `armv7r-none-eabi`.
> 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.
No different to any other arm-none-eabi 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.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate...
Same as other arm-none-eabi targets.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Same as other arm-none-eabi targets.
> 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.
Noted.
> 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.
Noted
> 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.)
Noted
Three targets, covering A32 and T32 instructions, and soft-float and
hard-float ABIs. Hard-float not available in Thumb mode. Atomics
in Thumb mode require __sync* functions from compiler-builtins.
Add Tier 3 Thumb-mode targets for Armv7-A, Armv7-R and Armv8-R
We currently have targets for bare-metal Armv7-R, Armv7-A and Armv8-R, but only in Arm mode. This PR adds five new targets enabling bare-metal support on these architectures in Thumb mode.
This has been tested using https://github.com/rust-embedded/aarch32/compare/main...thejpster:aarch32:support-thumb-mode-v7-v8?expand=1 and they all seem to work as expected.
However, I wasn't sure what to do with the maintainer lists as these are five new targets, but they share the docs page with the existing Arm versions. I can ask the Embedded Devices WG Arm Team about taking on these ones too, but whether Arm themselves want to take them on I guess is a bigger question.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#151010 (std: use `ByteStr`'s `Display` for `OsStr`)
- rust-lang/rust#151156 (Add GCC and the GCC codegen backend to build-manifest and rustup)
- rust-lang/rust#151219 (Fixed ICE when using function pointer as const generic parameter)
- rust-lang/rust#151343 (Port some crate level attrs to the attribute parser)
- rust-lang/rust#151463 (add x86_64-unknown-linux-gnuasan to CI)
r? @ghost
Add GCC and the GCC codegen backend to build-manifest and rustup
This PR adds the GCC codegen backend, and the GCC (libgccjit) component upon which it depends, to build-manifest, and thus also to (nightly) Rustup. I added both components in a single PR, because one can't work/isn't useful without the other.
Both components are marked as nightly-only and as `-preview`.
As a reminder, the GCC component is special; we need a separate component for every (host, target) compilation pair. This is not something that is really supported by rustup today, so we work around that by creating a separate component/package for each compilation target. So if we want to distribute GCC that can compile from {T1, T2} to {T2, T3}, we will create two separate components (`gcc-T2` and `gcc-T3`), and make both of them available on T1 and T2 hosts.
I tried to reuse the existing structure of `PkgType` in `build-manifest`, but added a target field to the `Gcc` package variant. This required some macro hackery, but at least it doesn't require making larger changes to `build-manifest`.
After this PR lands, unless I messed something up, starting with the following nightly, the following should work:
```bash
rustup +nightly component add rustc-codegen-gcc-preview gcc-x86_64-unknown-linux-gnu-preview
RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly build
```
Note that it will work currently only on `x86_64-unknown-linux-gnu`, and only if not cross-compiling.
r? @Mark-Simulacrum
Move bootstrap configuration to library workspace
This creates a new "dist" profile in the standard library which contains configuration for the distributed std artifacts previously contained in bootstrap, in order for a future build-std implementation to use. bootstrap.toml settings continue to override these defaults, as would any RUSTFLAGS provided. I've left some cargo features driven by bootstrap for a future patch.
Unfortunately, profiles aren't expressive enough to express per-target overrides, so [this risc-v example](https://github.com/rust-lang/rust/blob/c8f22ca269a1f2653ac962fe2bc21105065fd6cd/src/bootstrap/src/core/build_steps/compile.rs#L692) was not able to be moved across. This could go in its own profile which Cargo would have to know to use, and then the panic-abort rustflags overrides would need duplicating again. Doesn't seem like a sustainable solution as a couple similar overrides would explode the number of lines here.
We could use a cargo config in the library workspace for this, but this then would have to be respected by Cargo's build-std implementation and I'm not yet sure about the tradeoffs there.
This patch also introduces a build probe to deal with the test crate's stability which is obviously not ideal, I'm open to other solutions here or can back that change out for now if anyone prefers.
cc @Mark-Simulacrum https://github.com/rust-lang/rfcs/pull/3874
This uses a build probe to figure out the current toolchain version -
the only alternative to this is bespoke logic in Cargo to tell `test`
when the toolchain is stable/unstable.
The behaviour should be the same as when using
`CFG_DISABLE_UNSTABLE_FEATURES` unless an arbitrary channel is provided
to bootstrap, which I believe necessitates a fork anyway.
Create x86_64-unknown-linux-gnuasan target which enables ASAN by default
As suggested, in order to distribute sanitizer instrumented standard libraries without introducing new rustc flags, this adds a new dedicated target. With the target, we can distribute the instrumented standard libraries through a separate rustup component.
> A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)
The target is useful to anyone who wants to use ASAN with a stable compiler or the ease to not have to recompiled all standard libraries for full coverage.
> A tier 2 target must have a designated team of developers (the “target maintainers”) available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
> * The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.
I pledge myself and the folks from the Exploit Mitigations Project Group (rcvalle@ & 1c3t3a@) as target maintainers to fix target-specific issues and educate the Rust community about their use.
> The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.
Understood. The target should not have negative impact for anyone not using it.
> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.
`src/doc/rustc/src/platform-support/x86_64-unknown-linux-gnuasan.md` should provide the necessary documentation on how to build the target or compile programs with it. In the way the target can be emulated it should not differ from the tier 1 target `x86_64-unknown-linux-gnu`.
> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.
The baseline expectation mirror `x86_64-unknown-linux-gnu`.
> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
> * Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target’s maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
> * For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).
This has been outlined sufficiently. We should not enabled ASAN in the default target and are therefore creating a new tier 2 target to bridge the gap until `build-std` stabilized.
> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
> * The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
> * As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target’s value will take this limitation into account.
All of std that is supported by `x86_64-unknown-linux-gnu` is also supported.
> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target’s entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
> * For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
> * If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.
The entire point is to have more security instead of less ;) The safety properties provided are already present in the compiler, just not enabled by default.
> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.
Understood.
> The target must build reliably in CI, for all components that Rust’s CI considers mandatory.
Understood and the reason for introducing the tier 2 target.
> The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional “hello world” program, ./x.py test --no-run, or equivalent “smoke tests”. In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.
Understood.
> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.
Understood.
> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.
Understood. No need to use this target as the host (no benefit of having ASAN enabled for compiling).
> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
> * As an exception to this, if the target’s primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under “copyleft” terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust’s existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust’s standard license terms.
Understood, no legal differences between this target and `x86_64-unknown-linux-gnu`.
> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for 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 tests failing for the target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 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.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.
Understood.
> All requirements for tier 3 apply.
Requirements for tier 3 are listed below.
> 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 pledge to do my best maintaining it and we can also include the folks from the Exploit Mitigations Project Group (rcvalle@ & 1c3t3a@).
> 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.
We've chosen `x86_64-unknown-linux-gnuasan` as the name which was suggested on [#t-compiler/major changes > Create new Tier 2 targets with sanitizers… compiler-team#951 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Create.20new.20Tier.202.20targets.20with.20sanitizers.E2.80.A6.20compiler-team.23951/near/564482315).
> 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.
There should be no confusion, it's clear that it's the original target with ASAN enabled.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
Only letters, numbers and dashes used.
> 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 unusual requirements to build or use it. It's the original `x86_64-unknown-linux-gnu` target with ASAN enabled as a default sanitizer.
> The target must not introduce license incompatibilities.
There are no license implications.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Given, by reusing the existing ASAN code.
> 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.
There are no new dependencies/features required.
> 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.
It's using open source tools only.
> "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 such terms present.
> 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.
Understood.
> 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 goal is to have ASAN instrumented standard library variants of the existing `x86_64-unknown-linux-gnu` target, so all should be present.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
I think the explanation in platform support doc is enough to make this aspect clear.
> 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.
Understood.
> 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 don't believe this PR is affected by this.
> 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.)
The target should work on all rustc versions that correctly compile for `x86_64-unknown-linux-gnu`.
Jonathan Brouwer