v0 mangling for std on nightly
Following rust-lang/rust#89917 and rust-lang/compiler-team#938, it doesn't make sense that `std` for these channels would have legacy mangling while the user's code would use `v0`.
r? `@Kobzol`
This allows LTO to work when compiling jemalloc, which should yield a
small performance boost, and makes miri's behaviour here match clippy
and rustdoc.
automate gpu offloading - part 1
Automates step 1 from the rustc-dev-guide offload section:
https://rustc-dev-guide.rust-lang.org/offload/usage.html#compile-instructions
`"clang-offload-packager" "-o" "host.out" "--image=file=device.bc,triple=amdgcn-amd-amdhsa,arch=gfx90a,kind=openmp"`
Verified on an MI 250X
cc `@jhuber6,` `@kevinsala,` `@jdoerfert,` `@Sa4dUs`
r? oli-obk
Bump compiler dependencies
https://github.com/rust-lang/rust/pull/145849#issuecomment-3394832713
This manually downgrades the `wasip`/`wit-bindgen`/`getrandom` deps to avoid pulling in a binary blob, but it would be good to pin this automatically in a way which doesn't cause these blobs to be pulled in.
add `rust.rustflags` and per target `rustflags` options to `bootstrap.toml`
Part of rust-lang/rust#148782; see also rust-lang/rust#148708
Add new options `rust.rustflags` for all targets and `rustflags` par target that will pass specified flags to rustc for all stages. Target specific flags override (are passed after) global `rust.rustflags` ones.
This makes easy to persistently pass any flag to the compiler when building rustc. For example you can use a different linker by putting the following in `bootstrap.toml`:
```toml
[rust]
rustflags = ["-Clinker=clang", "-Clink-arg=--ld-path=wild"]
```
r? bootstrap
This makes easy to persistently pass any flag to the compiler when
building rustc.
For example you can use a different linker by putting the following in
`bootstrap.toml`:
```toml
[rust]
rustflags = ["-Clinker=clang", "-Clink-arg=--ld-path=wild"]
```
Build rustc and tools with -Zannotate-moves by default. Adds toml config
options to set the annotation size limit.
This has no measurable effect on output binary size or compile time.
Use rustc target metadata for build-manifest target lists
This ensures that as long as the target metadata is updated to reflect the current state (tier 3 vs 1/2, host toolchain support), the manifest will also be updated. This avoids an extremely common 'oops' when we move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't spot check against produced artifacts but given that they are tier 3 it's probably reasonable to leave it as-is and bug reporters can fix the target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of nightly/beta/stable builds as well, but for now this is simple and hopefully removes at common source of extra PRs when modifying targets.
Manifest list delta:
```diff
--- old
+++ new
-host:i686-apple-darwin
-host:mips-unknown-linux-gnu
-host:mips64-unknown-linux-gnuabi64
-host:mips64el-unknown-linux-gnuabi64
-host:mipsel-unknown-linux-gnu
-host:mipsisa32r6-unknown-linux-gnu
-host:mipsisa32r6el-unknown-linux-gnu
-host:mipsisa64r6-unknown-linux-gnuabi64
-host:mipsisa64r6el-unknown-linux-gnuabi64
-target:aarch64-unknown-hermit
-target:aarch64-unknown-managarm-mlibc
-target:aarch64-unknown-redox
-target:amdgcn-amd-amdhsa
-target:arm64e-apple-darwin
-target:arm64e-apple-ios
-target:arm64e-apple-tvos
-target:armebv7r-none-eabi
-target:armebv7r-none-eabihf
-target:armv7s-apple-ios
-target:bpfeb-unknown-none
-target:bpfel-unknown-none
-target:csky-unknown-linux-gnuabiv2
-target:csky-unknown-linux-gnuabiv2hf
-target:i386-apple-ios
-target:i586-unknown-redox
-target:i686-apple-darwin
-target:loongarch32-unknown-none
-target:loongarch32-unknown-none-softfloat
-target:m68k-unknown-linux-gnu
-target:m68k-unknown-none-elf
-target:mips-mti-none-elf
-target:mips-unknown-linux-gnu
-target:mips-unknown-linux-musl
-target:mips64-unknown-linux-gnuabi64
-target:mips64-unknown-linux-muslabi64
-target:mips64el-unknown-linux-gnuabi64
-target:mips64el-unknown-linux-muslabi64
-target:mipsel-mti-none-elf
-target:mipsel-unknown-linux-gnu
-target:mipsel-unknown-linux-musl
-target:mipsisa32r6-unknown-linux-gnu
-target:mipsisa32r6el-unknown-linux-gnu
-target:mipsisa64r6-unknown-linux-gnuabi64
-target:mipsisa64r6el-unknown-linux-gnuabi64
-target:riscv32gc-unknown-linux-gnu
-target:riscv32im-risc0-zkvm-elf
-target:riscv32ima-unknown-none-elf
-target:riscv64gc-unknown-hermit
-target:riscv64gc-unknown-linux-musl
-target:riscv64gc-unknown-managarm-mlibc
-target:sparc-unknown-none-elf
-target:x86_64-unikraft-linux-musl
-target:x86_64-unknown-hermit
-target:x86_64-unknown-managarm-mlibc
```
This ensures that as long as the target metadata is updated to reflect
the current state (tier 3 vs 1/2, host toolchain support), the manifest
will also be updated. This avoids an extremely common 'oops' when we
move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't
spot check against produced artifacts but given that they are tier 3
it's probably reasonable to leave it as-is and bug reporters can fix the
target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of
nightly/beta/stable builds as well, but for now this is simple and
hopefully removes at common source of extra PRs when modifying targets.
This is for people rebuilding stdlib directly from stage 0
with the full toolchain from rust-src rustup component.
The toolchain itself should have sufficient LLVM tools,
so CMake and LLVM are not required when `build.local-rebuild = true`
bootstrap: respect `build.python` on macOS
The `python()` method was hardcoded to return `/usr/bin/python3` on macOS, ignoring the `build.python` config option. This change respects the config while maintaining the system Python as the default.
The `python()` method was hardcoded to return `/usr/bin/python3` on
macOS, ignoring the `build.python` config option. This change respects
the config and removes the macOS-specific default.
compiletest: Run the `lldb_batchmode.py` script in LLDB's embedded Python
Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the `lldb` command directly.
Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings.
However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the `script` command.
bootstrap: Render doctest timing reports as text, not JSON
These doctest timing reports were added to libtest/rustdoc in https://github.com/rust-lang/rust/pull/144909, but bootstrap's custom test-output renderer wasn't taught about them, so they were being printed as raw JSON instead.
Before:
```text
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
```
After:
```text
all doctests ran in 0.73s; merged doctests compilation took 0.72s
```
<details>
<summary><b>Detailed before/after in context</b></summary>
## Before
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.28ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 403.67µs
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
finished in 1.505 seconds
Build completed successfully in 0:00:01
```
## After
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.12ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 395.67µs
all doctests ran in 0.73s; merged doctests compilation took 0.72s
finished in 1.493 seconds
Build completed successfully in 0:00:01
```
</details>
fix: disable self-contained linker when bootstrap-override-lld is set
Part of rust-lang/rust#148708.
Makes `rust.bootstrap-override-lld` set to `true` or `"external"` disable self-contained linker — actually using linker from one's system.
Fix rust-by-example spanish translation
A spanish translation was added in https://github.com/rust-lang/rust-by-example/pull/1910, but the upstream integration was never added.
```@marioidival,``` I assume you intended for this to go live?
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.
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
bors