Merged
Conversation
Tracks association between `self.sess.opts.externs` (aliases in `--extern alias=rlib`) and resolved `CrateNum` Intended to allow Rustdoc match the aliases in `--extern-html-root-url` Force-injected extern crates aren't included, since they're meant for the linker only
In favor of the adhoc `COMPILETEST_FORCE_STAGE0` env var.
…test-allow-stage0`
…explicitly allowed Otherwise, `compiletest` would have to know e.g. how to parse two different target spec, if target spec format was changed between beta `rustc` and in-tree `rustc`.
And move `./x test compiletest --stage=1` to `pr-check-2`, where testing library artifacts already requires building the stage 1 compiler.
Support multiple crate versions in --extern-html-root-url Rustdoc's `--extern-html-root-url` used to use `tcx.crate_name()` to identify crates, but that used crates' internal names from their metadata, instead of names given to them in `--extern`. That was confusing, because both `--extern…` arguments seem related and use similar syntax. Crucially, this didn't work correctly with Cargo's package aliases or multiple versions of crates. `sess.opts.externs` lacks `CrateNum`, and `Resolver.extern_prelude` gets destroyed before `rustdoc` has a chance to see it, so I've had to save this mapping in `CStore`. Just in case, I've kept the previous mapping by crate name as a fallback for crates that weren't matched by their extern name. Fixes rust-lang#76296
…s, r=lolbinarycat [rustdoc] Display total time and compilation time of merged doctests Fixes rust-lang#144270. Does it look good to you `@kpreid?` <img width="908" height="263" alt="image" src="https://github.com/user-attachments/assets/cd5d082d-c4e0-42ed-91dd-bd263b413dcd" />
…trs, r=WaffleLapkin clean up codegen fn attrs This honestly had become a mess over time and needed some love. No behavior should've changed, and I effectively just moved code around. Though, I can't promise there weren't any bugs in the original code with how randomly it was organised..... r? `@WaffleLapkin`
…bzol Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed Currently, in `pr-check-1`, we run `python3 ../x.py test --stage 0 src/tools/compiletest`, which is `compiletest` self-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, which `compiletest` depends on for target information, as otherwise `compiletest` would have to know how to handle 2 different target spec JSON formats and know when to pick which. Instead of doing that, we change `compiletest` self-tests to reject running against stage 0 `rustc` *unless* explicitly allowed with `build.compiletest-allow-stage0=true`. `build.compiletest-allow-stage0` is a proper bootstrap config option in favor of the ad-hoc `COMPILETEST_FORCE_STAGE0` env var. This means that: - `./x test src/tools/compiletest --stage=0` is not allowed, unless `build.compiletest-allow-stage0=true` is set. In this scenario, `compiletest` self-tests should be expected to fail unless the stage 0 `rustc` as provided is like codegen_cranelift where it's *actually* built from in-tree `rustc` sources. - In CI, we change `./x test src/tools/compiletest --stage=0` to `./x test src/tools/compiletest --stage=1`, and move it to `pr-check-2`. Yes, this involves building the stage 1 compiler, but `pr-check-2` already has to build stage 1 compiler to test stage 1 library crates. - Crucially, this means that **`compiletest` is only intended to support one target spec JSON format**, namely the one corresponding to the in-tree `rustc`. - This should preserve the `compiletest-use-stage0-libtest` UX optimization where changing `compiler/` tree should still not require rebuilding `compiletest` as long as `build.compiletest-use-stage0-libtest=true`, as that should remain orthogonal. This is completely unlike my previous attempt at rust-lang#144563 that tries to do a way more invasive change which would cause the rebuild problem. Best reviewed commit-by-commit. --- r? `@Kobzol`
rustbot
added
A-attributes
Member
Author
|
@bors r+ p=5 rollup=never |
Collaborator
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: e5e79f8bd4 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
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 e5e79f8 (parent) -> 3048886 (this PR) Test differencesShow 136 test diffsStage 0
Stage 1
Stage 2
(and 32 additional test diffs) Additionally, 4 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 3048886e59c94470e726ecaaf2add7242510ac11 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Jul 30, 2025
Collaborator
|
Finished benchmarking commit (3048886): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.5%, secondary -1.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 4.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 469.342s -> 470.294s (0.20%) |
Contributor
|
perf triage:
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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
9 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:
compiletestself-tests against stage 0 rustc unless explicitly allowed #144675 (Reject runningcompiletestself-tests against stage 0 rustc unless explicitly allowed)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup