Add build.rustdoc option to bootstrap config
This adds a bootstrap config option `build.rustdoc` to be able to override the stage0 `rustdoc` binary. When unspecified, this defaults to the existing behavior of using the `rustdoc` binary in the same directory as `rustc`, making this a backward-compatible change.
### Motivation
The existing behavior does not seem to be documented and can be surprising. By adding the new option, the behavior gets documented in `bootstrap.example.toml`.
I ran into this because I was experimenting with a build with a configuration like this:
```
build.rustc = "/usr/bin/rustc-1.92"
build.cargo = "/usr/bin/cargo-1.92"
```
This was on Ubuntu where the packages `rustc-1.92` and `cargo-1.92` place symlinks at these locations. This resulted in failure as the bootstrap process tried to run doc tests on `tidy` using a binary `/usr/bin/rustdoc` which did not exist. It took some digging to understand where that path `/usr/bin/rustdoc` was coming from.
@rustbot label +A-bootstrap-config
Build: Add `stdenv.cc.cc.lib` to Nix dependencies
Otherwise, it systematically fails on:
```
error: process didn't exit successfully: `[...]/rust/build/bootstrap/debug/rustc [...]/rust/build/bootstrap/debug/rustc -vV` (exit status: 127)
--- stderr
[...]/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
```
for us at least. Closesrust-lang/rust#127620.
@rustbot label T-bootstrap A-reproducibility
Remove `impl IntoQueryParam<P> for &'a P`.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so. In practice it's only used for passing `&DefId` to queries that accept `DefId`, which is an anti-pattern because `DefId` is marked with `#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil adjustments. (I generally avoid using `*` to deref manually at call sites, preferring to deref via `&` in patterns or via `*` in match expressions. Mostly because that way a single deref often covers multiple call sites.)
r? @cjgillot
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
Improve runtest revision redundant cfg check
While attempting to ingest https://github.com/rust-lang/rust/pull/148034 via https://github.com/ferrocene/ferrocene/pull/2172 we noticed a test failure, as we add some `compile_flags` to tests.
We saw a failure looking like this:
```
Testing stage1 with compiletest suite=mir-opt mode=mir-opt (x86_64-unknown-linux-gnu)
running 2 tests
2026-02-20T20:21:28.846102Z ERROR compiletest::runtest: redundant cfg argument `copy` is already created by the revision
[mir-opt] tests/mir-opt/pre-codegen/copy_and_clone.rs#COPY ... F
.
```
While my Rust checkout passed:
```
Testing stage1 with compiletest suite=mir-opt mode=mir-opt (x86_64-unknown-linux-gnu)
running 2 tests
..
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 381 filtered out; finished in 107.10ms
```
This caused me to add some debugging statements.
Ferrocene:
```
2026-02-20T21:05:39.808427Z ERROR compiletest::runtest: "copy": does ["--edition=2015", "--cfg=copy"] contain `"--cfg=copy"` or `["--cfg", "copy"]`? true
2026-02-20T21:05:39.808427Z ERROR compiletest::runtest: "clone": does ["--edition=2015"] contain `"--cfg=clone"` or `["--cfg", "clone"]`? false
2026-02-20T21:05:39.808435Z ERROR compiletest::runtest: redundant cfg argument `copy` is already created by the revision
```
Rust:
```
2026-02-20T21:04:18.493158Z ERROR compiletest::runtest: "copy": does ["--cfg=copy"] contain `"--cfg=copy"` or `["--cfg", "copy"]`? false
2026-02-20T21:04:18.493158Z ERROR compiletest::runtest: "clone": does [] contain `"--cfg=clone"` or `["--cfg", "clone"]`? false
```
I noticed while reviewing the related functionality that there is a call to `.windows(2)` in the relevant check for redundant cfgs:
https://github.com/rust-lang/rust/blob/0376d43d443cba463a0b6a6ec9140ea17d7b7130/src/tools/compiletest/src/runtest.rs#L507-L511
Noting:
https://github.com/rust-lang/rust/blob/0376d43d443cba463a0b6a6ec9140ea17d7b7130/library/core/src/slice/mod.rs#L1064-L1066
Because of this, the revision check was getting an empty iterator when `self.props.compile_flags` was length 0 or 1.
This fix adjusts the check to handle such cases.
I went ahead and fixed the relevant test (4b3cd9b289ce0a36bda2756321f5fe455ea301e1) that was impacted by this. I do not suspect there are others, at least within the scope that Ferrocene tests, as we have not previously seen this failure.
Update cargo submodule
10 commits in ce69df6f72a3b6a2b5c722ba68ddef255344b31c..8cc0cb136772b8f54eafe0d163fcb7226a06af0c
2026-02-12 12:39:45 +0000 to 2026-02-17 12:16:26 +0000
- docs(layout): Updated layout module docs to document new layout (rust-lang/cargo#16502)
- fix(host-config): host.linker should not apply to non host unit (rust-lang/cargo#16641)
- init: improve error message and add tests (rust-lang/cargo#16643)
- Corrected doc comment for build script root_output path (rust-lang/cargo#16645)
- Changed build script run `output` dir to `stdout` in new build-dir layout (rust-lang/cargo#16644)
- test: add test case for verify-project with invalid TOML (rust-lang/cargo#16640)
- test(script): Show remaining workspace behavors (rust-lang/cargo#16633)
- fix(host-config): `host.runner` should not apply to `cargo run` (rust-lang/cargo#16638)
- refactor(help): simplify code structure (rust-lang/cargo#16627)
- test: Remove unused docker ip_address (rust-lang/cargo#16636)
The convert_if_to_bool_then assist was producing incorrect code when
the Some branch was in the else arm and the condition was a method call
expression (e.g. is_empty()).
Before:
if test.is_empty() { None } else { Some(()) }
was incorrectly rewritten to:
test.is_empty().then(|| ())
After (correct):
(!test.is_empty()).then(|| ())
Root cause: the parenthesization check ran on the original condition
before inversion. When invert_boolean_expression produced a PrefixExpr
(e.g. !test.is_empty()), it was not being parenthesized because the
check had already passed on the original MethodCallExpr.
Fix: move the parenthesization check to after the inversion step so it
correctly detects PrefixExpr and wraps it in parentheses.
A regression test has been added to cover this case.
Previously, `self.props.compile_flags.windows(2)` would return an empty
iterator in the case where `self.props.compile_flags` was 1 or 0 length.
This created incorrectness where tests like
`tests/mir-opt/pre-codegen/copy_and_clone.rs` would pass when they should fail.
Not linting irrefutable_let_patterns on let chains
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146832)*
# Description
this PR makes the lint `irrefutable_let_patterns` not check for `let chains`,
only check for single `if let`, `while let`, and `if let guard`.
# Motivation
Since `let chains` were stabilized, the following code has become common:
```rust
fn max() -> usize { 42 }
fn main() {
if let mx = max() && mx < usize::MAX { /* */ }
}
```
This code naturally expresses "please call that function and then do something if the return value satisfies a condition".
Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent.
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src/main.rs:7:8
|
7 | if let mx = max() && mx < usize::MAX {
| ^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
```
Another common case is progressively destructuring a struct with enum fields, or an enum with struct variants:
```rust
struct NameOfOuterStruct {
middle: NameOfMiddleEnum,
other: (),
}
enum NameOfMiddleEnum {
Inner(NameOfInnerStruct),
Other(()),
}
struct NameOfInnerStruct {
id: u32,
}
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct { middle, .. } = outer
&& let NameOfMiddleEnum::Inner(inner) = middle
&& let NameOfInnerStruct { id } = inner
{
/* */
}
}
```
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src\main.rs:17:8
|
17 | if let NameOfOuterStruct { middle, .. } = outer
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
warning: trailing irrefutable pattern in let chain
--> src\main.rs:19:12
|
19 | && let NameOfInnerStruct { id } = inner
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it into the body
```
To avoid the warning, the readability would be much worse:
```rust
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct {
middle: NameOfMiddleEnum::Inner(NameOfInnerStruct { id }),
..
} = outer
{
/* */
}
}
```
# related issue
* rust-lang/rust#139369
# possible questions
1. Moving the irrefutable pattern at the head of the chain out of it would cause a variable that was intended to be temporary to remain in scope, so we remove it.
However, should we keep the check for moving the irrefutable pattern at the tail into the body?
2. Should we still lint `entire chain is made up of irrefutable let`?
---
This is my first time contributing non-documentation code to Rust. If there are any irregularities, please feel free to point them out.
: )
Add bootstrap snapshot tests for {`install`, `install src`}
And `install src` with `build.docs = false`.
This is mostly to get coverage for the baseline to make it easier to review rust-lang/rust#150845.
bootstrap: respect POSIX jobserver
When bootstrapping Rust, the `-j N` flag was passed to CMake, which was
then forwarded to Ninja. This prevents the jobserver from being used,
and as a result leads to oversubscription when Rust is just one of the
many packages built as part of a larger software stack.
Since Cargo and the Rust compiler have long supported the jobserver, it
would be good if also bootstrapping Rust itself would participate in the
protocol, leading to composable parallelism.
This change allows bootstrapping to respect an existing FIFO based
jobserver. Old pipe based jobservers are not supported, because they are
brittle: currently the Python scripts in bootstrap do not inherit the
file descriptors, but do pass on `MAKEFLAGS`, which has lead to errors
like "invalid file descriptor" in the past. Because Ninja only supports
FIFO based jobservers, it's better to focus on new jobservers only,
which shouldn't suffer from the "invalid file descriptor" issue.
In summary:
* Bootstrap Cargo passes `MAKEFLAGS` verbatim to subprocesses if it
advertises a FIFO style jobserver, otherwise it unsets it. This ensures
subprocesses respect the jobserver during bootstrap.
* `llvm.rs` does not pass `-j` to `cmake` when a FIFO style jobserver is
set in `MAKEFLAGS`. This ensures Ninja respects the jobserver.
* Bootstrap Cargo no longer unsets `MKFLAGS`: from git blame, GNU Make
considered it a historical artifact back in 1992, and it is never read
by GNU Make, it's only set for backwards compatibility in case sub-Makefiles
read it.
---
I've tested this with the [Spack package manager](https://github.com/spack/spack) starting the POSIX jobserver,
building node.js and rust in parallel with `-j16`, which looks like this:
```console
$ pstree 382710
python3─┬─python3
└─python3─┬─python3─┬─make───make───6*[ccache───g++───cc1plus]
│ └─{python3}
└─python3─┬─python3.11───bootstrap───cmake───ninja-build───10*[sh───ccache───g++───cc1plus]
└─{python3}
```
As you can see there are 10 `g++` processes running for rust, and `6` for node.js, and
with a mix of `make` and `ninja` as build tools :).
(The only violation I see now is `rust-lld`, but I think that'll be fixed with the LLVM 23
release)
Otherwise, it systematically fails on:
```
error: process didn't exit successfully: `[...]/rust/build/bootstrap/debug/rustc [...]/rust/build/bootstrap/debug/rustc -vV` (exit status: 127)
--- stderr
[...]/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
```
for us at least.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Since llvm/llvm-project 159143, llvm no longer weak links the __cpp_exception tag into
each object that uses it. They are now defined in compiler-rt. Rust doesn't seem to
get them from compiler-rt so llvm decides they need to be imported. This adds them to
libunwind.
Jonathan Brouwer