Consolidate stage directories and group logs in bootstrap
My post-stage-0-redesign bootstrap fixes aren't done yet, but I think that enough steps have been migrated to the new system that it makes sense to actually modify the directories on disk, and what gets printed when bootstrap runs, so that it actually corresponds to the new system. Before, the printed stages didn't always make sense.
This PR:
- Fixes the numbering of `stageN` directories in the build directory. It was not corresponding to the correct stages before; notice that I did not modify `bootstrap/README.md`, as it was essentially describing what happens after this PR (first commit).
- Unifies all steps that output a build group to use the `Builder::msg` method. It's probably not the final stage, and some of the test steps might not be fully accurate yet, because I didn't fix test step numbering yet, but I think that it's a clear improvement from before, and now that everything uses the same method, we can easily make changes across the board, to ensure that it stays unified (second commit).
r? `@jieyouxu`
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
Make no_mangle on foreign items explicit instead of implicit
for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it.
I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :)
Builds on rust-lang/rust#144655 which should merge first.
bootstrap: Only warn about `rust.debug-assertions` if downloading rustc
The changes in rust-lang/rust#145149 had the unwanted side-effect of causing bootstrap to *always* warn about `rust.debug-assertions = true`, even if rustc isn't going to be downloaded anyway.
cc ``@Shourya742`` ``@Kobzol``
Account for new `assert!` desugaring in `!condition` suggestion
`rustc` in https://github.com/rust-lang/rust/pull/122661 is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>` while not being `bool` itself no longer a straightforward suggestion, but `!!condition` will coerce the expression to be `bool`, so it can be machine applicable.
Transposing https://github.com/rust-lang/rust-clippy/pull/15453/ to the rustc repo.
r? `````@samueltardieu`````
Update books
## rust-lang/reference
6 commits in 1be151c051a082b542548c62cafbcb055fa8944f..59b8af811886313577615c2cf0e045f01faed88b
2025-08-10 18:21:53 UTC to 2025-08-08 01:00:04 UTC
- Add LoongArch32 to inline-assembly documentation (rust-lang/reference#1942)
- Update `no_builtins` to use the attribute template (rust-lang/reference#1909)
- Update `global_allocator` to use the attribute template (rust-lang/reference#1919)
- Update `windows_subsystem` to use the attribute template (rust-lang/reference#1920)
- Remove note on accepted invalid `should_panic` syntax (rust-lang/reference#1955)
- specify relative drop order of pattern bindings (rust-lang/reference#1953)
## rust-lang/rust-by-example
1 commits in bd1279cdc9865bfff605e741fb76a0b2f07314a7..adc1f3b9012ad3255eea2054ca30596a953d053d
2025-08-08 12:02:24 UTC to 2025-08-08 12:02:24 UTC
- Update Chinese translations in `zh.po` (rust-lang/rust-by-example#1950)
Document compiler and stdlib in stage1 in `pr-check-2` CI job
This restores the original behavior pre-https://github.com/rust-lang/rust/pull/145011 (I thought that stage 2 makes more sense here, but it made the job ~30m slower, which is bad).
Let's see what will be the "new" duration, it should be ~55 minutes.
r? ```````@jieyouxu```````
Rename entered trace span variables from `_span` to `_trace`
This PR just changes the name of `EnteredTraceSpan` variables used to automatically close tracing spans when going out of scope. This renaming was needed because `_span` could possibly be confused with the `Span` type in rustc, so I used `_trace` as suggested in https://github.com/rust-lang/rust/pull/144727#discussion_r2247267670.
Extract TraitImplHeader in AST/HIR
Several fields of `Impl` are only applicable when it's a trait impl. This moves those fields into a new struct that is only present for trait impls.
Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var
Fixes https://github.com/rust-lang/rust/issues/80817, fixes https://github.com/rust-lang/rust/issues/96943, and generally simplifies our linker invocation on Apple platforms.
Part of https://github.com/rust-lang/rust/issues/129432.
### Necessary background on trampoline binaries
The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`.
This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly):
- `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk`
- `LIBRARY_PATH=/usr/local/lib` (appended)
- `CPATH=/usr/local/include` (appended)
- `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended)
This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools.
(It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`).
### Finding a suitable SDK
All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above).
But relying on the `cc` trampoline doesn't work when:
- Cross-compiling, since a different SDK is needed there.
- Invoking the linker directly, since the linker doesn't understand `SDKROOT`.
- Linking build scripts inside Xcode (see https://github.com/rust-lang/rust/issues/80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified.
Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**.
Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below.
#### No Xcode
There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`.
We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit.
#### `SDKROOT` vs. `-isysroot`
The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang/rust#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option.
To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it.
One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any?
In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool.
Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`).
### Considered alternatives
- Invoke `/usr/bin/cc` instead of `cc`.
- This breaks many other use-cases though where overriding `cc` in the PATH is desired.
- Look up `which cc`, and do special logic if in Xcode toolchain.
- Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical.
- Invoke `xcrun --sdk macosx cc`.
- This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable.
- Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible.
- Bundle the SDK, similar to `zig-cc`.
- Comes with it's own host of problems.
### Testing
Tested that this works with the following `-Clinker=...`:
- [x] Default (`cc`)
- [x] `/usr/bin/ld`
- [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`)
- [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`)
- [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK)
- [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK)
- [x] ~Macports `clang`~ Couldn't get it to build
- [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK)
- [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK)
- [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK)
- [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK)
- [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`)
CC ```````@BlackHoleFox``````` ```````@thomcc```````
`rustc` is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>`
while not being `bool` itself no longer a straightforward suggestion,
but `!!condition` will coerce the expression to be `bool`, so it can be
machine applicable.
This is more in-line with what Apple's tooling expects, and allows us to
better support custom compiler drivers (such as certain Homebrew and
Nixpkgs compilers) that prefer their own `-isysroot` flag.
Effectively, we now invoke the compiler driver as-if it was invoked as
`xcrun -sdk $sdk_name $tool`.
Ship correct Cranelift library in its dist component
The first commit adds a post-dist UI test to check that Cranelift can be used with the extracted dist x64 Linux archive.
The original codegen copy logic in the Cranelift dist step was a bit redundant, and I didn't notice in https://github.com/rust-lang/rust/pull/144787 that it's copying the codegen backend from the build compiler's sysroot, rather than the target compiler's sysroot. The second commit modifies the logic to directly access the built codegen file (there is no need to search for it in the compiler's sysroot, in fact when you run just `x dist rustc_codegen_cranelift`, it shouldn't "taint" the sysroot with the codegen backend! Which it did before https://github.com/rust-lang/rust/pull/144787) and copy it to the tarball under a normalized name. Thus we get around any similar potential issues in the future, and make previously implicit logic more explicit.
This also fixes running just `x dist rustc_codegen_cranelift` without enabling `cranelift` in `rust.codegen-backends`, which should have been enabled by https://github.com/rust-lang/rust/pull/144787, but it didn't work fully, because the dist step tried to copy the codegen backend from the compiler's sysroot, but it didn't contain the codegen backend if it was not enabled by `rust.codegen-backends`.
Fixes: https://github.com/rust-lang/rust/issues/145201
try-job: dist-x86_64-linux
Fix Cargo cross-compilation (take two)
In https://github.com/rust-lang/rust/pull/145083, I fixed the case of manually invoking `x dist cargo`, but I realized that `x install` creates the `tool::Cargo` step through the `from_build_frompiler` constructor, which doesn't go through `get_tool_target_compiler`. So we just prepare both the host and target stdlibs directly before building Cargo. Ideally we would get rid of `from_build_compiler`, but that will require refactoring the dist and test steps, which is upcoming.
Hopefully fixes https://github.com/rust-lang/rust/issues/145059 for good.
