Rollup of 14 pull requests by JonathanBrouwer · Pull Request #163661 · rust-lang/rust

JonathanBrouwer · 2026-10-02T14:08:21Z

Successful merges:

Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs" #163582 (Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs")
Add mul_add_relaxed methods for floating-point types #151793 (Add mul_add_relaxed methods for floating-point types)
Fix rustdoc ICE caused by mishandling of ambiguity errors #162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors)
Miri can do dirfd now #163010 (Miri can do dirfd now)
Improve DocStrings perf #163535 (Improve DocStrings perf)
Fix TypeOutlives fast-path #163576 (Fix TypeOutlives fast-path)
Several small span improvements #163587 (Several small span improvements)
Reorganise reflection intrinsics #163603 (Reorganise reflection intrinsics)
fix ValidateBoundVars #163612 (fix ValidateBoundVars)
bump rustc-build-sysroot #163632 (bump rustc-build-sysroot)
Revert note about signum of NaN #163635 (Revert note about signum of NaN)
Add mailmap entry #163644 (Add mailmap entry)
Rename rustc_driver::run_compiler to compiler_entrypoint #163647 (Rename rustc_driver::run_compiler to compiler_entrypoint)
Remove variants from feature-gate-autodiff-use test #163651 (Remove variants from feature-gate-autodiff-use test)

@camelid

Takes a different approach to rust-lang#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang#159854). --- This reverts commit c84edb3.

Limit changes: - Increase `MAX_CTXT`: it is currently `0b0111_1111_1111_1110` (~15 bits). But it only needs to be distinguishable from `CTXT_INTERNED_MARKER` (all 1s). So we can increase it to `0b1111_1111_1111_1110` (~16 bits). The old limit is rarely reached; the `uom` crate is an exception (it has 39k contexts) and we see a 1-2% instruction count reduction when building it. (This value was incorrectly reduced from ~16 bits to ~15 bits in e525e4f by me; apologies!) Renamings: - Rename `MAX_CTXT` as `MAX_CTXT_OR_PARENT` because it also relates to the parent field. - Remove the `BASE_` prefix from `BASE_LEN_INTERNED_MARKER` because it doesn't mean anything. Comments: - Update parts of the comment that predate the addition of the `parent` field, such as the frequency measurements. (In incremental builds, 20-40% internment due to non-root context and non-zero parent is common.) - Slightly clarify the meanings of the fields in the different forms, and add a paragraph quickly explaining which specific values distinguish the four forms.

…NaNs" This reverts commit 88db34a.

Having two `run_compiler` functions has always been confusing and not necessary at all, as they perform fairly different functions. Even more so because `rustc_driver::run_compiler` calls to `rustc_interface::run_compiler`. So it seems like a recursive function when it really isn't.

@jieyouxu

…cci, r=Kobzol Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs" Reverts rust-lang#162339 Re-applies rust-lang#161716 and rust-lang#162318 Since a new beta has been released between then and now, the fix applied in rust-lang#162346 is in beta, so the code should work. r? @jieyouxu

…rust-lang#151770, r=tgross35 Add mul_add_relaxed methods for floating-point types Implements mul_add_relaxed for f16, f32, f64, and f128, which computes (self * a) + b with relaxed precision semantics. Unlike mul_add which guarantees a fused operation, this variant allows the compiler to choose between fused or separate operations based on target performance. This fills the gap between the precision-guaranteed mul_add and the fully-optimizable algebraic operators, providing target-specific optimization while maintaining reasonable floating-point semantics. Tracking issue: rust-lang#151770 try-job: dist-i586-gnu-i586-i686-musl

Fix rustdoc ICE caused by mishandling of ambiguity errors Fixes rust-lang#162557 ```rust pub trait Service<Request> { type Future; } pub trait ZebraService<Request>: Service<Request> {} impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where MaybeVerify: Service<Request, Future: 'static> { } pub struct Verifier; impl Service<()> for Verifier { type Future = &'static (); } ``` In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`, https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67 We make fresh args for the where-clause and skip normalization for it. So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars. But due rust-lang#162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region. So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code. But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs. r? lcnr

…mulacrum Miri can do dirfd now So let's remove some special-casing from the standard library. Fixes rust-lang/miri#5327

…-perf, r=nnethercote Improve `DocStrings` perf Follow-up of rust-lang#162862. r? ghost

@lcnr

…=lcnr Fix `TypeOutlives` fast-path > Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path: > > `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases > > This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush: _Originally posted by @lcnr in rust-lang#162782 (comment) The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD. We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver. I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but.. - It's no-less-correct than the status quo - It roughly matches the actual non-fast path: https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129 - The later has some perf impact hard to ignore for `typenum` I couldn't conjure up any case fixed by this PR other than the one in rust-lang#162782 😅 r? lcnr

@petrochenkov

…s, r=petrochenkov Several small span improvements Limit changes: - Increase `MAX_CTXT`: it is currently `0b0111_1111_1111_1110` (~15 bits). But it only needs to be distinguishable from `CTXT_INTERNED_MARKER` (all 1s). So we can increase it to `0b1111_1111_1111_1110` (~16 bits). The old limit is rarely reached; the `uom` crate is an exception (it has 39k contexts) and we see a 1-2% instruction count reduction when building it. (This value was incorrectly reduced from ~16 bits to ~15 bits in e525e4f by me; apologies!) Renamings: - Rename `MAX_CTXT` as `MAX_CTXT_OR_PARENT` because it also relates to the parent field. - Remove the `BASE_` prefix from `BASE_LEN_INTERNED_MARKER` because it doesn't mean anything. Comments: - Update parts of the comment that predate the addition of the `parent` field, such as the frequency measurements. (In incremental builds, 20-40% internment due to non-root context and non-zero parent is common.) - Slightly clarify the meanings of the fields in the different forms, and add a paragraph quickly explaining which specific values distinguish the four forms. r? @petrochenkov

…i-obk Reorganise reflection intrinsics Trivial refactor moving some things around. We got a fair amount of intrinsics for reflection now with more on the way. At this point it's worth it to reorganize things a little. This prefixes them with `type_id_` (`TypeId` is the entry point for _nearly_ all of reflection) and moves their declaration into its own module (`core::intrinsics::reflection`). Possible contentious is the move of the `type_id` intrinsic which has existed for a while and was previously at `core::intrinsics::type_id`. It is still unstable and as far as I am aware intrinsics should really not be relied upon by users. I've decided to leave the `field_representing_field` (name, offset, actual_type_of) where they are since those where not created for reflection and will be changed in the future (see: rust-lang#162127). r? oli-obk

…i-obk fix `ValidateBoundVars` `ControlFlow::Break` is just wrong. We want to visit later types even if we skip the current one. The `t.outer_exclusive_binder() <= self.binder_index` check is more subtle. See the flag computation https://github.com/rust-lang/rust/blob/29df41c47187f735942d13900b784962ef1bc140/compiler/rustc_type_ir/src/flags.rs#L217-L218 It is the exclusive binder. The first binder for which there exist no bound vars. This is subtle and was found while asking an LLM to help with perrrrf, only for me to then be confused for 10 min while checking whether this is right :< r? types

@oli-obk

…-obk bump rustc-build-sysroot Fixes rust-lang/miri#5371 r? @oli-obk

Revert note about signum of NaN See: rust-lang#162576 (comment)

@LoriLorusso

Add mailmap entry Done at the request of the user. CC @LoriLorusso

…piler_entrypoint, r=oli-obk Rename `rustc_driver::run_compiler` to `compiler_entrypoint` Having two `run_compiler` functions has always been confusing and not necessary at all, as they perform fairly different functions. Even more so because `rustc_driver::run_compiler` calls to `rustc_interface::run_compiler`. So it seems like a recursive function when it really isn't.

JonathanBrouwer · 2026-10-02T14:08:33Z

@bors r+ p=5 force

Trying commonly failed jobs
@bors try jobs=dist-various-1,test-various,test-x86_64-gnu-aux,test-x86_64-gnu-llvm-21-3,test-x86_64-msvc-1,test-aarch64-apple-1,test-aarch64-apple-2,test-x86_64-mingw-1,test-i686-msvc,test-armhf-gnu

rust-bors · 2026-10-02T14:08:37Z

📌 Commit f784deb has been approved by JonathanBrouwer

It is now in the queue for this repository.

Rollup of 14 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-gnu-llvm-21-3 try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu

rust-bors · 2026-10-02T17:01:34Z

☀️ Try build successful (CI)
Build commit: c544e8a (c544e8a3fdc1ca3550ef6f38045f1467de437ba4)
Base parent: c165834 (c1658342b0ea7eab61db1960082668c77f553522)

rust-bors · 2026-10-02T20:25:33Z

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 7m 42s
Pushing 0abfedb to main...

github-actions · 2026-10-02T20:29:04Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing da51be1 (parent) -> 0abfedb (this PR)

Test differences

Show 462 test diffs

Stage 0

core::builder::tests::snapshot::dist_compiler_docs: pass -> [missing] (J3)
core::builder::tests::snapshot::doc_compiler_with_tools: [missing] -> pass (J3)

Stage 1

[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs: [missing] -> pass (J1)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#nightly: pass -> [missing] (J1)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#stable: ignore (only executed when the release channel is stable) -> [missing] (J1)
[ui] tests/ui/intrinsics/float-mul-add-relaxed.rs: [missing] -> pass (J1)
[ui (polonius)] tests/ui/feature-gates/feature-gate-autodiff-use.rs: [missing] -> pass (J2)
[ui (polonius)] tests/ui/feature-gates/feature-gate-autodiff-use.rs#nightly: pass -> [missing] (J2)
[ui (polonius)] tests/ui/feature-gates/feature-gate-autodiff-use.rs#stable: ignore (only executed when the release channel is stable) -> [missing] (J2)
[ui (polonius)] tests/ui/intrinsics/float-mul-add-relaxed.rs: [missing] -> pass (J2)
[rustdoc-json] tests/rustdoc-json/impls/blanket-ambig-on-nonrigid-assoc-next-solver.rs: [missing] -> pass (J7)

Stage 2

[rustdoc-json] tests/rustdoc-json/impls/blanket-ambig-on-nonrigid-assoc-next-solver.rs: [missing] -> pass (J0)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#nightly: pass -> [missing] (J4)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#stable: ignore (only executed when the release channel is stable) -> [missing] (J4)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs: [missing] -> pass (J5)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#nightly: ignore (only executed when the release channel is nightly) -> [missing] (J6)
[ui] tests/ui/feature-gates/feature-gate-autodiff-use.rs#stable: pass -> [missing] (J6)
[ui] tests/ui/intrinsics/float-mul-add-relaxed.rs: [missing] -> pass (J8)

Additionally, 444 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 0abfedbc7cd4e725f126913880c95800394f7c37 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

test-x86_64-gnu-stdlib-semver-check: 8m 58s -> 18m 37s (+107.6%)
test-x86_64-gnu-gcc: 53m 1s -> 1h 26m (+62.4%)
optional-test-x86_64-gnu-autodiff: 34m 43s -> 56m (+61.3%)
dist-sparcv9-solaris: 1h 9m -> 1h 46m (+52.9%)
test-x86_64-gnu-debug: 1h 35m -> 2h 13m (+40.5%)
dist-riscv64-linux-musl: 1h 7m -> 1h 33m (+37.8%)
dist-x86_64-llvm-mingw: 1h 34m -> 2h 9m (+36.7%)
test-x86_64-gnu-nopt: 2h 31m -> 1h 38m (-34.7%)
dist-armhf-linux: 1h 11m -> 1h 34m (+33.0%)
test-x86_64-gnu-aux: 2h -> 2h 39m (+32.2%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-10-02T21:10:30Z

Finished benchmarking commit (0abfedb): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	6
Regressions ❌ (secondary)	0.2%	[0.1%, 0.4%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	0.1%	[0.1%, 0.1%]	6

Max RSS (memory usage)

Results (primary -0.7%, secondary 1.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.0%	[2.0%, 3.9%]	6
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-2.9%	[-3.3%, -2.7%]	3
All ❌✅ (primary)	-0.7%	[-0.7%, -0.7%]	1

Cycles

Results (primary 2.1%, secondary 1.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	5.0%	[2.1%, 10.7%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.8%, -2.1%]	3
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Conversation

JonathanBrouwer commented Oct 2, 2026

Uh oh!

JonathanBrouwer commented Oct 2, 2026

Uh oh!

rust-bors Bot commented Oct 2, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 2, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 2, 2026

Uh oh!

Uh oh!

github-actions Bot commented Oct 2, 2026

Test differences

Stage 0

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Oct 2, 2026

Overall result: ❌ regressions - please read:

Uh oh!

rust-bors Bot commented Oct 2, 2026

Uh oh!

JonathanBrouwer commented Oct 2, 2026

Uh oh!

rust-timer commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

#163582 e99ff00 Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs"

#151793 850430a Add mul_add_relaxed methods for floating-point types

#162782 4f8baea Fix rustdoc ICE caused by mishandling of ambiguity errors

#163010 f848460 Miri can do dirfd now

#163535 fae4eae Improve DocStrings perf

#163576 bc39e1e Fix TypeOutlives fast-path

#163587 04c3c2a Several small span improvements

#163603 91c8ec4 Reorganise reflection intrinsics

#163612 e0bcdbd fix ValidateBoundVars

#163632 e76456f bump rustc-build-sysroot

#163635 291adc7 Revert note about signum of NaN

#163644 da5919b Add mailmap entry

#163647 a4ffb7a Rename rustc_driver::run_compiler to compiler_entrypoint

#163651 472fbf2 Remove variants from feature-gate-autodiff-use test

Uh oh!

JonathanBrouwer commented Oct 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

rust-timer commented Oct 2, 2026 •

edited

Loading

#163582 `e99ff00` Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs"

#151793 `850430a` Add mul_add_relaxed methods for floating-point types

#162782 `4f8baea` Fix rustdoc ICE caused by mishandling of ambiguity errors

#163010 `f848460` Miri can do dirfd now

#163535 `fae4eae` Improve `DocStrings` perf

#163576 `bc39e1e` Fix `TypeOutlives` fast-path

#163587 `04c3c2a` Several small span improvements

#163603 `91c8ec4` Reorganise reflection intrinsics

#163612 `e0bcdbd` fix `ValidateBoundVars`

#163632 `e76456f` bump rustc-build-sysroot

#163635 `291adc7` Revert note about signum of NaN

#163644 `da5919b` Add mailmap entry

#163647 `a4ffb7a` Rename `rustc_driver::run_compiler` to `compiler_entrypoint`

#163651 `472fbf2` Remove variants from `feature-gate-autodiff-use` test