-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
do not build additional stage on compiler paths #137882
Conversation
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler. The changes applied fix this issue. Signed-off-by: onur-ozkan <work@onurozkan.dev>
first(builder.cache.all::<compile::Assemble>()), | ||
&[ | ||
rustc!(TEST_TRIPLE_1 => TEST_TRIPLE_1, stage = 0), | ||
rustc!(TEST_TRIPLE_1 => TEST_TRIPLE_1, stage = 1), | ||
rustc!(TEST_TRIPLE_1 => TEST_TRIPLE_1, stage = 2), | ||
rustc!(TEST_TRIPLE_1 => TEST_TRIPLE_2, stage = 1), | ||
rustc!(TEST_TRIPLE_1 => TEST_TRIPLE_2, stage = 2), | ||
compile::Assemble { | ||
target_compiler: Compiler { | ||
host: TargetSelection::from_user(TEST_TRIPLE_1), | ||
stage: 0 | ||
} | ||
}, | ||
compile::Assemble { | ||
target_compiler: Compiler { | ||
host: TargetSelection::from_user(TEST_TRIPLE_1), | ||
stage: 1 | ||
} | ||
}, | ||
compile::Assemble { | ||
target_compiler: Compiler { | ||
host: TargetSelection::from_user(TEST_TRIPLE_1), | ||
stage: 2 | ||
} | ||
}, | ||
compile::Assemble { | ||
target_compiler: Compiler { | ||
host: TargetSelection::from_user(TEST_TRIPLE_2), | ||
stage: 2 | ||
} | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would include stage3 compiler on master.
@rustbot ready r? bootstrap |
Signed-off-by: onur-ozkan <work@onurozkan.dev>
bd24ae8
to
cfb475c
Compare
One of those PRs where @bors r+ |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
Yeah, it has saved me lots of hours in my recent works.. |
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#135767 (Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies) - rust-lang#137852 (Remove layouting dead code for non-array SIMD types.) - rust-lang#137863 (Fix pretty printing of unsafe binders) - rust-lang#137882 (do not build additional stage on compiler paths) - rust-lang#137894 (Revert "store ScalarPair via memset when one side is undef and the other side can be memset") - rust-lang#137902 (Make `ast::TokenKind` more like `lexer::TokenKind`) - rust-lang#137921 (Subtree update of `rust-analyzer`) - rust-lang#137922 (A few cleanups after the removal of `cfg(not(parallel))`) - rust-lang#137939 (fix order on shl impl) - rust-lang#137946 (Fix docker run-local docs) - rust-lang#137955 (Always allow rustdoc-json tests to contain long lines) - rust-lang#137958 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search) r? `@ghost` `@rustbot` modify labels: rollup
I'm a bit confused by |
Can you say more about |
Rollup merge of rust-lang#137882 - onur-ozkan:remove-extra-compiler-stage, r=Kobzol do not build additional stage on compiler paths When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler. The changes applied fix this issue. r? ghost
So, my understanding is that My confusion is that |
|
Before this change, After this change, Also note that this new behaviour is now inconsistent with |
To make it clear, this change makes
|
Ah, I think the reason It still builds the stage 1 compiler, of course, but only because having a working stage 1 compiler is required for other things (e.g. |
This broke the rustc-perf bootstrap benchmark, because it does |
Yeah, previous |
This is not a bug fix; it's an ad-hoc breaking change to how stage numbering works for There are arguments for and against that, but I'm concerned that nobody involved seems to understand or acknowledge that this is what's happening. After this PR, The reason
It was not magically incrementing the stage. It was using the stage N compiler, as requested, to build the compiler. The result of doing that is the stage N+1 compiler. That's why the +1 was deliberately included. After this PR, |
Yeah I am aware that, but why do you think it was not a default
That's exactly what was the problem with Rustc tools and many people was arguing about it for years, which is fixed with #137215. |
When calling
x build compiler (or rustc) --stage N
bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when runningx build --stage N
without explicitly targeting the compiler.The changes applied fix this issue.
r? ghost