Install additional LLVM DLL on Windows
Fixes https://github.com/rust-lang/rust/issues/155268
The problem is that with shared linking to LLVM lib we have binaries requiring it in `$sysroot/bin` and `$sysroot/lib/rustlib/triple/bin`, but place the DLL only in the first location. On Unix systems rpath would take care of that, but on Windows the required DLL must be next to the binary or be found in PATH.
This PR puts another copy of the library into that second location. The size overhead of such copy compared to static linking is much lower than I anticipated even though I couldn't manage to make bootstrap create hard links.
The sizes without and with `llvm-tools` component:
```
❯ du --summarize -h .rustup/toolchains/{additional-dll,static}*
638M .rustup/toolchains/additional-dll
800M .rustup/toolchains/additional-dll-tools
608M .rustup/toolchains/static-link
1.1G .rustup/toolchains/static-link-tools
```
Statically linked LLD sits at 139M while dynamically linked one is 7.5M + 150M for the libLLVM, so the difference is minor.
Alternatively, we could require that on Windows, binaries located in `$sysroot/lib/rustlib/triple/bin` must always be called with `$sysroot/bin` in the PATH. However, that sounds like something that would require an announcement and some grace period.
Include vendored sources in the rust-src component
In the future this can be used by build-std, but until then it is still useful for allowing rust-analyzer to work offline.
This increases the unpacked size by 24MB (from 116MB to 140MB) and the compressed size by only 2MB (from 18MB to 20MB)
bootstrap: Don't panic on `x install --set build.extended=true`
This was a regression from rust-lang/rust#155732.
The Cargo submodule wasn't checked out, so reading from Cargo.toml didn't work. Return a fake version during dry-runs to avoid unnecessarily checking out submodules.
Fixes https://github.com/rust-lang/rust/issues/156408.
This was a regression from 155732.
The Cargo submodule wasn't checked out, so reading from Cargo.toml
didn't work. Return a fake version during dry-runs to avoid
unnecessarily checking out submodules.
Support `-Cpanic=unwind` on WASI targets
This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here).
* The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too.
The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets.
Finally, this ends up closing rust-lang/rust#154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against.
Closesrust-lang/rust#154593
This commit is some minor updates/restructuring in a few locations with
the end result being supporting `-Cpanic=unwind` on WASI targets. This
continues to be off-by-default insofar as WASI targets default to
`-Cpanic=abort`, meaning that actually using anything in this commit
requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of
`libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also
updated here).
* The `unwind` crate here in this repository uses the `libunwind` module
instead of the custom bare-metal wasm implementation of exceptions.
This means that Rust uses the `_Unwind_*` symbols which allows it to
interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument
`-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of
using the legacy exception handling proposal for WebAssembly. This has
no effect by default because `panic=abort` is used on most targets.
Emscripten is exempted from this as the Emscripten target is
explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the
`panic_unwind` crate which ended up requiring `-Wexceptions` from
Wasmtime, so the test parts were updated and Wasmtime was updated in
CI, too.
The net result of all of this is that this should not actually affect
any WebAssembly target's default behavior. Optionally, though, WASI
programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary
to enable this support on wasm targets.
Finally, this ends up closing 154593 as well. The WASI targets are now
defined to use `-lunwind` to implement unwinding. This means that the
in-tree definition of `__cpp_exception` is no longer of concern and the
definition is always sourced externally. If Rust is linked with other
C/C++ code using WASI then these idioms are compatible with wasi-sdk,
for example, to use that as a linker. The main caveat is that when using
an external linker the `-fwasm-exceptions` argument needs to be passed
to `clang` for it to be able to find the `libunwind.a` library to link
against.
Closes 154593
In the future this can be used by build-std, but until then it is still
useful for allowing rust-analyzer to work offline.
This increases the unpacked size by 24MB (from 116MB to 140MB) and the
compressed size by only 2MB (from 18MB to 20MB)
Fix alias path for rustdoc
I ran this command:
```console
x build --stage 1 --skip rustdoc
Building bootstrap
Compiling bootstrap v0.0.0 (/Users/yukang/rust/src/bootstrap)
Finished `dev` profile [unoptimized] target(s) in 1.08s
/Users/yukang/rust/build/aarch64-apple-darwin/ci-llvm/bin/llvm-strip does not exist; skipping copy
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.45s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 library artifacts{alloc, compiler_builtins, core, panic_abort, panic_unwind, proc_macro, rustc-std-workspace-core, std, std_detect, sysroot, test, unwind} (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized + debuginfo] target(s) in 0.10s
Skipping Set({build::src/tools/rustdoc}) because it is excluded
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.19s
```
expect all `rustdoc` related compiling phase will be exlcuded, but from the log we can see `rustdoc_tool_binary` is still compiled.
`src/tools/rustdoc` and `src/librustdoc` are documented as aliases in path set here:
https://github.com/rust-lang/rust/blob/a25435bcf7cfc9b953d356eda3a51db8da9e3386/src/bootstrap/src/core/builder/mod.rs#L355-L360
we can also see here two paths are treated as alias:
https://github.com/rust-lang/rust/blob/a25435bcf7cfc9b953d356eda3a51db8da9e3386/src/bootstrap/src/core/build_steps/check.rs#L818-L822
but bootstrap registered them as two different sets with `.path(..).path(...)`:
https://github.com/rust-lang/rust/blob/a25435bcf7cfc9b953d356eda3a51db8da9e3386/src/bootstrap/src/core/build_steps/tool.rs#L691-L693
That meant commands like `x build --skip rustdoc`, `--skip src/tools/rustdoc`, or `--skip src/librustdoc` only excluded one side.
linker-messages is warn-by-default again
cc rust-lang/rust#136096
I ended up keeping it a lint and adding an option for lints to ignore `-Dwarnings` (there was already a lint that did that actually, it was just hard-coded in rustc_middle instead of in rustc_lint_defs like I'd expect). This allows people to actually see the warnings without them failing the build in CI.
switch to v0 mangling by default on stable
Following rust-lang/rust#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs:
- rust-lang/rust#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants)
- rust-lang/rust#134479 only occurs with unstable `generic_const_exprs`
Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable.
This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up.
r? @wesleywiser
This made it very annoying to debug bootstrap itself, because every
`--dry-run` invocation would start out by cloning LLVM, which is almost
never necessary. Instead change a few Steps to properly support dry_run
when no submodule is checked out.
This adds a `--quiet` flag to x.py and bootstrap to suppress some of the
output when compiling Rust. It conflicts with `--verbose`, matching the
behavior of `cargo` which does not allow `--verbose` and `--quiet`.
It works by passing quiet flags down to the underlying cargo, or LLVM
build processes. Note that for LLVM, we only can suppress logs when we
explicitly configure it with ninja. Otherwise we won't know what flag
to pass along to whichever build system cmake decides to use.
This can be helpful with AI workloads in the Rust codebase to help
shrink down the output to reduce token usage, which can help prevent
context pollution and lower costs.
This patch was partially generated with Gemini, but I've reviewed the
changes it made.
Fix manpage version replacement and use verbose version
- Fix a bug where `t!(fs::copy(&page_src, &page_dst))` was called after`fs::write`, silently overwriting the substituted content with the original template (restoring the `<INSERT VERSION HERE>` placeholder verbatim) (Related rust-lang/rust#93685)
- Use `rust_info().version()` instead of the bare version number, so the man page now includes the full version string with commit hash and date
Add a flag to control verbose subprocess output for run-make tests. When using --no-capture on panic=abort test suites like cg_clif, passing test output can flood the terminal. This flag (default true) lets users opt out via --verbose-run-make-subprocess-output=false.
Extract a private print_command_output helper in run-make-support to avoid inlining the output logic in handle_failed_output, ensuring failures always print regardless of the flag.
Currently all downloaded rustc and LLVM components are auto patched on
NixOS, but this is not done for libgccjit.so, so when GCC backend is
enabled on NixOS, the build ICEs with errors like this:
thread 'rustc' (2286205) panicked at compiler/rustc_codegen_gcc/src/lib.rs:191:9:
Cannot load libgccjit.so: libzstd.so.1: cannot open shared object file: No such file or directory
Fix this by auto-patch libgccjit.so, too. `zstd` is added to the dependency
environment.
Signed-off-by: Gary Guo <gary@garyguo.net>
Anything that can change there can also be changed in bootstrap.toml.
We have a separate check to make sure that the local config is
compatable with CI's config.
Example output:
```
$ x b compiler
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.02s
NOTE: detected 3 modifications that could affect a build of rustc
- src/bootstrap/src/core/config/config.rs
- src/bootstrap/src/core/download.rs
- src/build_helper/src/git.rs
skipping rustc download due to `download-rustc = 'if-unchanged'`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.72s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Build completed successfully in 0:00:05
```
CI jobs were sometimes hanging because cargo would inherit the jobserver based the MFLAGS
environment variable when it contained file descriptors. However, these FDs were not
valid, since bootstrap.py does not pass them through from make.
This leads cargo's job server to use invalid FDs when setting up the
jobserver.
Bootstrap had a mitigation for this when it came from MAKEFLAGS,
but not when it came from MFLAGS.
Jonathan Brouwer