Skip to content

Enforce in bootstrap that build must have stage at least 1 #142581

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 26, 2025

Conversation

Kobzol
Copy link
Contributor

@Kobzol Kobzol commented Jun 16, 2025

This PR is a step towards https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523586917. It's very hard or me to make self-contained changes to bootstrap at this moment, so this PR kind of does several things:

  1. (first two commits) Try to reduce the usage of Std::new in bootstrap, and replace it with a Builder::std method (similar to Builder::compiler). This is mostly to remove executions of the Std step for stage 0, which doesn't make a lot of sense; I'd like to ideally have the invariant that when a step is invoked, it actually builds or does something. Eventually, I'd like for everything to go through Builder::std. (Note: I'm not totally married to this idea, if you don't like it, we can remove it from this PR. I mostly did it right now to remove stage 0 std steps from snapshot tests, which shouldn't be there, but we can also filter them out in a different way)
  2. Make sure that when you pass x build compiler, only the Assemble root level step will be invoked, and not the Rustc step. Before, both were invoked, which actually ran Rustc twice, once with all crates filled, and once with no crates (but both actually represent the same situation). Since the Rustc::make_run step actually requests a compile that is one stage below it, this actually made build compiler --stage 0 work, which we don't want to have anymore.
  3. Enforce a bootstrap-global invariant that all build commands are always on stage >=1. If you try to build anything on stage 0, it will print a warning and exit bootstrap. This follows the intuition from the new staging rules after the stage redesign; artifacts that are "stage 0" come outside of bootstrap, and we can't really build something for which we don't have source (although we can still test it, but that's for another PR).

Now the logic for build should be quite simple. For pretty much everything except for Std, you first use the stage0 compiler to build stage 1. Then you can build a stage 2 using the previously built stage 1 (and then you can continue to stage 3 etc.). And that's it. The default build stage for everything is 1 (modulo download-ci-rustc, but that's a separate can of worms).

The snapshot test infra isn't super nice at the moment, as one of next steps I want to create some simple Builder pattern that will allow us to configure the bootstrap invocations in a more "forward-compatible" way (e.g. now it's not possible to modify the config passed to configure_with_args).

There are some things not yet fully resolved for build stage 0:

  1. Cargo is still a ModeRustc tool, even though it doesn't really have to be, it is buildable with the stage0 compiler
  2. bootstrap tools (opt-dist, build-manifest etc.) are still called stage0 tools, and in the bootstrap output it says something like "stage 0 rustc builds stage 0 opt-dist". Which is a bit weird, but functionally there's no difference, it's just a slightly inconsistent output. We still haven't decided if we should make these tools ignore staging altogether (which is IMO the right choice) or if we want to allow building stage 1/2/3/... bootstrap tools.

r? @jieyouxu

try-job: x86_64-rust-for-linux

@rustbot
Copy link
Collaborator

rustbot commented Jun 16, 2025

jieyouxu is not on the review rotation at the moment.
They may take a while to respond.

@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. labels Jun 16, 2025
@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 16, 2025

This actually interacts with cross-compilation, as I mentioned here:

./x build --host 'i686-unknown-linux-gnu'
thread 'main' panicked at src/bootstrap/src/core/builder/mod.rs:1344:17:
It is not possible to build the standard library for `i686-unknown-linux-gnu` using the stage0 compiler.
You have to build a stage1 compiler for `x86_64-unknown-linux-gnu` first, and then use it to build a standard library for `i686-unknown-linux-gnu`.

You need to pass --stage 2 now to make this work. Yet another trade-off between "bootstrap keeping explicit stages for commands" vs "bootstrap should just make stuff work somehow"...

@rust-log-analyzer

This comment has been minimized.

@Kobzol Kobzol marked this pull request as ready for review June 17, 2025 07:12
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 17, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 17, 2025

This PR modifies src/bootstrap/defaults.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

@Kobzol Kobzol force-pushed the bootstrap-std-method branch from 49ed3f9 to 6bf0ab7 Compare June 17, 2025 07:15
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Kobzol Kobzol marked this pull request as draft June 17, 2025 14:26
Comment on lines 1011 to 1058
// Now check that the selected stage makes sense, and if not, print a warning and end
match (config.stage, &config.cmd) {
(0, Subcommand::Build) => {
eprintln!("WARNING: cannot build anything on stage 0. Use at least stage 1.");
exit!(1)
}
_ => {}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: if we warn on the no-op that is ./x build --stage=0, what about ./x check --stage=0? I guess for the check case, we can't do that yet without untying bootstrap tool checking from staging?

Also, does this reject e.g. ./x build src/tools/opt-dist --stage=0?

EDIT: indeed,

    #[test]
    #[should_panic]
    fn build_bootstrap_tool_stage_0() {
        insta::assert_snapshot!(get_steps("opt-dist", "build", Some(0)), @"");
    }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check is a whole another beast, I'm working on a PR for it, but the individual bootstrap kinds (build/check/etc.) are mostly separate in the stage handling, so I will do it piece by piece.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, I'm planning for check --stage 0 to also be an error.

Comment on lines +1016 to +1029
// If only `compiler` was passed, do not run this step.
// Instead the `Assemble` step will take care of compiling Rustc.
if run.builder.paths == vec![PathBuf::from("compiler")] {
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remark: this kinda feels iffy, in that I feel like the path filtering/handling logic that lead to

Rustc step was invoked twice, once with all crates and once with no crates (even though both of these mean the same thing).

makes this kinda weird.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love Rustc and Assemble to be just one step (to avoid things like this), but I guess that it's sort of an optimizatoin, Rustc allows building only selected crates, and doesn't involve building a ton of other things that you might not want for a quick build.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that does make sense.

@jieyouxu
Copy link
Member

jieyouxu commented Jun 18, 2025

I'm generally in favor of imposing more discipline (or more order, for that matter) on build staging as is done in this PR. Not super sure about rejecting ./x build <bootstrap_tool> --stage=0. Would like a second opinion.

Maybe r? @Mark-Simulacrum

@rustbot rustbot assigned Mark-Simulacrum and unassigned jieyouxu Jun 18, 2025
@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 18, 2025

Not super sure about rejecting ./x build <bootstrap_tool> --stage=0. Would like a second opinion.

That depends on how we decide #t-infra/bootstrap > Proposal to cleanup stages and steps after the redesign. The bootstrap tools don't really participate in staging (unless you're cross-compiling, but we don't even support cross-compiling these tools, as they are host tools, essentially). So in theory we could allow them to be built with whatever --stage you pass. However, to achieve better consistency in bootstrap staging, they should in fact be treated stage 1 tools, as they are built with a stage 0 compiler. If we force their stage to be 1, I don't think that the error on --stage 0 should anger anyone, the most natural thing (x build <host-tool>) should just work. No need to pass --stage 0.

@bors
Copy link
Collaborator

bors commented Jun 18, 2025

☔ The latest upstream changes (presumably #142685) made this pull request unmergeable. Please resolve the merge conflicts.

@Kobzol Kobzol force-pushed the bootstrap-std-method branch from f8a105c to 809f750 Compare June 23, 2025 08:11
@Kobzol Kobzol marked this pull request as ready for review June 23, 2025 08:11
@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 23, 2025

The pre-requisite PRs have finally landed, so I ported this PR on top of the new config test builder and step metadata. Now it should be hopefully quite clear which (important) steps are being executed when we do x build compiler/library/<rustc-tool>/<bootstrap-tool> [--stage 0/1/2].

@jieyouxu Could you please take another looks? Thanks!

@jieyouxu jieyouxu self-assigned this Jun 23, 2025
@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 23, 2025

I had to port a bunch of tests to the new snapshot test suite. Some of them were duplicated or seemed quite dubious, so I removed a few of them.

I expect that several step traces are not ideal here (in particular around cross-compilation), and we might want to re-evaluate them. But I would only do it after we finish the renumbering for check/clippy/test kinds and also for tools, which are all kinds of special. To avoid any intermediate hacks before we see how the staging traces work after everything has been ported.

@jieyouxu
Copy link
Member

Not super sure about rejecting ./x build <bootstrap_tool> --stage=0. Would like a second opinion.

That depends on how we decide #t-infra/bootstrap > Proposal to cleanup stages and steps after the redesign. The bootstrap tools don't really participate in staging (unless you're cross-compiling, but we don't even support cross-compiling these tools, as they are host tools, essentially). So in theory we could allow them to be built with whatever --stage you pass. However, to achieve better consistency in bootstrap staging, they should in fact be treated stage 1 tools, as they are built with a stage 0 compiler. If we force their stage to be 1, I don't think that the error on --stage 0 should anger anyone, the most natural thing (x build <host-tool>) should just work. No need to pass --stage 0.

I think this goes back to what Ralf described as the "staging boundary" right? As in, where do you do a stage cut-off.

However, to achieve better consistency in bootstrap staging, they should in fact be treated stage 1 tools, as they are built with a stage 0 compiler.

Sounds a bit weird to me at first, because the stage 1 library is built with the stage 1 compiler, but now bootstrap tools (stage 1 too in this PR) are built with the stage 0 compiler. Previously, they were stuffed to stage 0, because the reasoning is moreso that "it's built by the stage 0 compiler".

After reading https://hackmd.io/QXj6LqntQTKPgm3uBuE-aA, I think I can see that with

This document assumes the "stage corresponds to what gets built, not what is used to build it" model. This is a consequence of the terminology introduced above. Stage 1 rustc is simply the first rustc built by bootstrap, stage 1 std is the first std built by bootstrap etc.
With this model, it does not seem to make sense to do anything with stage 0 sources.

In the sense that bootstrap tools were built from in-tree sources. I still feel a bit... confused, mentally, by this model. I think I can understand "well, you have to pick a mental model", and I can appreciate that trying to fit various kinds of "tools" into this mental model and making this coherent/self-consistent and easy to comprehend is not exactly trivial.

@rust-lang/bootstrap thoughts?

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall implementation looks good. Just a few nits/questions, and also see previously the discussion re. mental model.

Comment on lines +792 to +796
StepMetadata::build("rustdoc", self.compiler.host)
// rustdoc is ToolRustc, so stage N rustdoc is built by stage N-1 rustc
// FIXME: make this stage deduction automatic somehow
// FIXME: log the compiler that actually built ToolRustc steps
.stage(self.compiler.stage.saturating_sub(1)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion [MENTAL-MODEL 1/N]: for example, like trying to fit rustc-tools into a self-consistent/coherent mental model

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I already have a follow-up branch prepared that works on tools. They are so painful.. and also duplicated across check/build. I still have to untangle this mess, and move some tools to different modes.

Comment on lines +669 to +670
// Cross-compilation fails on stage 1, as we don't have a stage0 std available
// for non-host targets.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion [MENTAL-MODEL]: I think this makes sense, and I would agree that we should strive for correctness -- for example, don't try to do magic stage promotions/adjustments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'd rather just disable cross-compilation at stage 1 than do the magical step promotion. I was in the opposite opinion camp just a few weeks ago, but after investigating bootstrap in detail, I have switched opinions =D

Comment on lines +875 to +883
#[test]
fn build_bootstrap_tool_stage_2() {
let ctx = TestCtx::new();
insta::assert_snapshot!(
ctx.config("build")
.path("opt-dist")
.stage(2)
.render_steps(), @"[build] rustc 0 <host> -> OptimizedDist <host>");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: I almost wonder if we should issue a warning for the case where you try to ./x build <bootstrap-tool> --stage=2, but since bootstrap tools are stage-agnostic, so to speak, this mental model is still coherent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it could be a warning. I'd leave that for a different PR though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 25, 2025

In the sense that bootstrap tools were built from in-tree sources. I still feel a bit... confused, mentally, by this model. I think I can understand "well, you have to pick a mental model", and I can appreciate that trying to fit various kinds of "tools" into this mental model and making this coherent/self-consistent and easy to comprehend is not exactly trivial.

So far (unless we find yet another exception), the "new" mental model is:

  • If you're std stage N, you're built with rustc stage N
  • If you're anything else stage N, you're built with rustc stage N - 1

I think that's simple enough.

@jieyouxu
Copy link
Member

Okay, that does seem reasonable to me.

@jieyouxu
Copy link
Member

To me, the current set of changes looks more consistent. I'd like to have a second pair of eyes on this though, so.

@jieyouxu jieyouxu requested a review from Mark-Simulacrum June 25, 2025 12:35
@jieyouxu
Copy link
Member

Actually @Kobzol could you add

the "new" mental model is:

  • If you're std stage N, you're built with rustc stage N
  • If you're anything else stage N, you're built with rustc stage N - 1

In the rustc-dev-guide bootstrap chapter somewhere, to establish what contributors should interpret the stage meaning as?

@jieyouxu
Copy link
Member

Otherwise, I think we should merge this, there are some hard self-consistency fixes that need this invariant and test coverage (e.g. to work towards fixing #142505 properly).

@Kobzol
Copy link
Contributor Author

Kobzol commented Jun 26, 2025

Happy to document this, but I'm not sure if it isn't premature? In the sense that check/clippy/test and possibly other stuff doesn't fully uphold this mental model yet.

@jieyouxu
Copy link
Member

Right.

@jieyouxu
Copy link
Member

Okay, I looked at this again, it does seem more self-consistent to me. I'm going to give this some p, as this is a prerequisite to fixing download-rustc staging problems.
@bors r+ rollup=never p=10 (needed for further bootstrap consistency fixes)

@bors
Copy link
Collaborator

bors commented Jun 26, 2025

📌 Commit e69c023 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 26, 2025
@bors
Copy link
Collaborator

bors commented Jun 26, 2025

⌛ Testing commit e69c023 with merge 8f21a5c...

@bors
Copy link
Collaborator

bors commented Jun 26, 2025

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 8f21a5c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 26, 2025
@bors bors merged commit 8f21a5c into rust-lang:master Jun 26, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jun 26, 2025
@Kobzol Kobzol deleted the bootstrap-std-method branch June 26, 2025 12:19
Copy link
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 1e83852 (parent) -> 8f21a5c (this PR)

Test differences

Show 51 test diffs

Stage 0

  • core::builder::tests::alias_and_path_for_library: pass -> [missing] (J0)
  • core::builder::tests::defaults::build_cross_compile: pass -> [missing] (J0)
  • core::builder::tests::defaults::build_default: pass -> [missing] (J0)
  • core::builder::tests::defaults::build_stage_0: pass -> [missing] (J0)
  • core::builder::tests::dist::build_all: pass -> [missing] (J0)
  • core::builder::tests::dist::build_with_empty_host: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_all_cross: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_baseline: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_only_cross_host: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_with_empty_host: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_with_hosts: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_with_same_targets_and_hosts: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_with_targets: pass -> [missing] (J0)
  • core::builder::tests::dist::dist_with_targets_and_hosts: pass -> [missing] (J0)
  • core::builder::tests::dist::test_docs: pass -> [missing] (J0)
  • core::builder::tests::dist::test_with_no_doc_stage0: pass -> [missing] (J0)
  • core::builder::tests::snapshot::alias_and_path_for_library: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_all: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_bootstrap_tool_no_explicit_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_bootstrap_tool_stage_0: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_bootstrap_tool_stage_1: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_bootstrap_tool_stage_2: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_compiler_no_explicit_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_compiler_stage_0: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_compiler_stage_1: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_compiler_stage_2: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_cross_compile: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_default: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_default_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_library_no_explicit_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_library_stage_0: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_library_stage_1: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_library_stage_2: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_miri_no_explicit_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_miri_stage_0: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_miri_stage_1: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_miri_stage_2: [missing] -> pass (J0)
  • core::builder::tests::snapshot::build_with_empty_host: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_all_cross: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_baseline: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_default_stage: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_extended: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_with_empty_host: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_with_hosts: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_with_targets: [missing] -> pass (J0)
  • core::builder::tests::snapshot::dist_with_targets_and_hosts: [missing] -> pass (J0)
  • core::builder::tests::snapshot::test_exclude: [missing] -> pass (J0)
  • core::builder::tests::snapshot::test_exclude_kind: [missing] -> pass (J0)
  • core::builder::tests::staging::build_compiler_stage_1: pass -> [missing] (J0)
  • core::builder::tests::test_exclude: pass -> [missing] (J0)
  • core::builder::tests::test_exclude_kind: pass -> [missing] (J0)

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 8f21a5c92ea55c348c275a1bc4fedbdf181e0d64 --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

  1. dist-aarch64-apple: 4753.0s -> 6441.5s (35.5%)
  2. x86_64-apple-1: 9333.7s -> 6713.2s (-28.1%)
  3. dist-x86_64-apple: 9545.4s -> 7529.1s (-21.1%)
  4. x86_64-apple-2: 4585.3s -> 5531.8s (20.6%)
  5. dist-apple-various: 8379.5s -> 9349.8s (11.6%)
  6. x86_64-gnu-llvm-19-3: 6357.7s -> 6925.5s (8.9%)
  7. x86_64-gnu-llvm-20-3: 5993.8s -> 6387.4s (6.6%)
  8. dist-android: 2719.2s -> 2563.8s (-5.7%)
  9. x86_64-msvc-ext1: 6836.4s -> 7161.0s (4.7%)
  10. x86_64-gnu-llvm-19-2: 5408.7s -> 5646.1s (4.4%)
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
Copy link
Collaborator

Finished benchmarking commit (8f21a5c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 5.9%, secondary -2.8%)

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

mean range count
Regressions ❌
(primary)
5.9% [5.9%, 5.9%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.8% [-3.9%, -2.2%] 3
All ❌✅ (primary) 5.9% [5.9%, 5.9%] 1

Cycles

Results (secondary 10.3%)

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)
10.3% [3.6%, 12.0%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 691.88s -> 691.142s (-0.11%)
Artifact size: 372.13 MiB -> 372.05 MiB (-0.02%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants