Rollup of 8 pull requests - #163650
Closed
JonathanBrouwer wants to merge 23 commits into
Closed
Rollup of 8 pull requests#163650JonathanBrouwer wants to merge 23 commits into
JonathanBrouwer wants to merge 23 commits into
Conversation
CodegenContext will in the future be serialized and deserialized into a different rustc instance when -Zno-link/-Zlink-only is used. A separate incr comp session has to be used for both rustc invocations.
Previously we would copy post LTO artifacts into the incr comp cache for fat LTO despite them never getting used. Also the pre LTO bitcode didn't get tracked and thus determine_cgu_reuse believed it had to regenerate bitcode for all CGUs even when all CGUs would be green.
Co-authored-by: Bruno Kolenbrander <59372212+mejrs@users.noreply.github.com>
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.
…NaNs" This reverts commit 88db34a.
Fix incremental compilation for fat LTO Previously we would copy post-LTO artifacts into the incr comp cache for fat LTO despite them never getting used. Also the pre-LTO bitcode didn't get tracked and thus `determine_cgu_reuse` believed it had to regenerate bitcode for all CGUs even when all CGUs would be green. Also move incr comp session dirs out of `CodegenContext`. `CodegenContext` will in the future be serialized and deserialized into a different rustc instance when `-Zno-link`/`-Zlink-only` is used. A separate incr comp session has to be used for both rustc invocations. Part of rust-lang/compiler-team#908
…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
…=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
…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
…-obk bump rustc-build-sysroot Fixes rust-lang/miri#5371 r? @oli-obk
Revert note about signum of NaN See: rust-lang#162576 (comment)
rustbot
added
A-LLVM
rustbot
added
T-rustdoc
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 2, 2026
Rollup of 8 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
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for 49f0ab8 failed: CI. Failed job:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
TypeOutlivesfast-path #163576 (FixTypeOutlivesfast-path)ValidateBoundVars#163612 (fixValidateBoundVars)r? @ghost
Create a similar rollup