Prepare for additional enums like Vendor and Os which have true
`Unknown` variants. We want to use the same name for the escape hatch
for all of these, thus rename this one.
Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Add LLVM realtime sanitizer
This is a new attempt at adding the [LLVM real-time sanitizer](https://clang.llvm.org/docs/RealtimeSanitizer.html) to rust.
Previously this was attempted in https://github.com/rust-lang/rfcs/pull/3766.
Since then the `sanitize` attribute was introduced in https://github.com/rust-lang/rust/pull/142681 and it is a lot more flexible than the old `no_santize` attribute. This allows adding real-time sanitizer without the need for a new attribute, like it was proposed in the RFC. Because i only add a new value to a existing command line flag and to a attribute i don't think an MCP is necessary.
Currently real-time santizer is usable in rust code with the [rtsan-standalone](https://crates.io/crates/rtsan-standalone) crate. This downloads or builds the sanitizer runtime and then links it into the rust binary.
The first commit adds support for more detailed sanitizer information.
The second commit then actually adds real-time sanitizer.
The third adds a warning against using real-time sanitizer with async functions, cloures and blocks because it doesn't behave as expected when used with async functions. I am not sure if this is actually wanted, so i kept it in a seperate commit.
The fourth commit adds the documentation for real-time sanitizer.
Offload device
LLVM's offload functionality usually expects an extra dyn_ptr argument. We could avoid it,b ut likely gonna need it very soon in one of the follow-up PRs (e.g. to request shared memory). So we might as well already add it.
This PR adds a %dyn_ptr ptr to GPUKernel ABI functions, if the offload feature is enabled.
WIP
r? ```@ghost```
Add default sanitizers to TargetOptions
Some sanitizers are part of a system's ABI, like the shadow call stack on Aarch64 and RISC-V Fuchsia. Typically ABI options have other spellings, but LLVM has, for historical reasons, marked this as a sanitizer instead of an alternate ABI option. As a result, Fuchsia targets may not be compiled against the correct ABI unless this option is set. This hasn't caused correctness problems, since the backend reserves the SCS register, and thus preserves its value. But this is an issue for unwinding, as the SCS will not be an array of PCs describing the call complete call chain, and will have gaps from callers that don't use the correct ABI.
In the long term, I'd like to see all the sanitizer configs that all frontends copy from clang moved into llvm's libFrontend, and exposed so that frontend consumers can use a small set of simple APIs to use sanitizers in a consistent way across the LLVM ecosystem, but that work is not yet ready today.
Unify the configuration of the compiler docs
Previously it was rather inconsistent which crates got the rust logo and which didn't and setting html_root_url was forgotten in many cases.
Relax r29 inline asm restriction on PowerPC64 targets
LLVM uses r29 to hold a base pointer for some PowerPC target configurations. It is usable on all 64 bit targets as a callee save register.
r? `@Amanieu`
Stabilize `fmt::from_fn`
Resolvesrust-lang/rust#146705, pending its FCP.
As discussed in that tracking issue and rust-lang/rust#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
Some sanitizers are part of a system's ABI, like the shadow call stack
on Aarch64 and RISC-V Fuchsia. Typically ABI options have other
spellings, but LLVM has, for historical reasons, marked this as a
sanitizer instead of an alternate ABI option. As a result, Fuchsia
targets may not be compiled against the correct ABI unless this option
is set. This hasn't caused correctness problems, since the backend
reserves the SCS register, and thus preserves its value. But this is an
issue for unwinding, as the SCS will not be an array of PCs describing
the call complete call chain, and will have gaps from callers that don't
use the correct ABI.
In the long term, I'd like to see all the sanitizer configs that all
frontends copy from clang moved into llvm's libFrontend, and exposed so
that frontend consumers can use a small set of simple APIs to use
sanitizers in a consistent way across the LLVM ecosystem, but that work
is not yet ready today.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#135602 (Tweak output of missing lifetime on associated type)
- rust-lang/rust#139751 (Implement pin-project in pattern matching for `&pin mut|const T`)
- rust-lang/rust#142682 (Update bundled musl to 1.2.5)
- rust-lang/rust#148171 (Simplify code to generate line numbers in highlight)
- rust-lang/rust#148263 (Unpin `libc` and `rustix` in `compiler` and `rustbook`)
- rust-lang/rust#148301 ([rustdoc search] Include extern crates when filtering on `import`)
- rust-lang/rust#148330 (Don't require dlltool with the dummy backend on MinGW)
- rust-lang/rust#148338 (cleanup: upstream dropped amx-transpose functionality)
- rust-lang/rust#148340 (Clippy subtree update)
- rust-lang/rust#148343 (`nonpoison::Condvar` should take `MutexGuard` by reference)
r? `@ghost`
`@rustbot` modify labels: rollup
cleanup: upstream dropped amx-transpose functionality
See also LLVM change 5322fb626820. Looks like this was just removed entirely.
It seems a little bad to just drop it, but I don't see an easy way to conditionalize
this and if it's really just Gone and we marked it as unstable (which it looks like
we did?) I guess we should just dump it.
````@rustbot```` label llvm-main
Targets theoretically possible, but not provided yet:
- 32-bit arm
See also notes in the PR, I was unable to run anything non-trivial on ARM HelenOS, there are issues
with the linker/loader, incomplete support of atomics, and overall a lot of confusion about
the precise version of ARM architecture that the HelenOS builds target.
- riscv, mips (These targets currently don't run HelenOS at all. HelenOS says it should work, but the builds are broken for quite some time now.)
Align VEX V5 boot routine to 4 bytes
This PR fixes an alignment issue with the initialization routine on the VEX V5 target.
Previously, if the `.text` output section contained any functions aligned to more than four bytes, the linker would add padding bytes before the beginning of `.text` rather than changing the position of the aligned function inside the section itself. This is an issue because the entry point for the program needs to be located at `0x3800_0020` on this platform and the addition of padding could cause it to be moved.
To fix this, I've forced the start address of the `.text` section to be aligned to 4 bytes so that the entry point is placed consistently. Items inside the section can still be aligned to values larger than this.
