Fix uplifting in `Assemble` step by Kobzol · Pull Request #145557 · rust-lang/rust

Kobzol · 2025-08-18T08:17:46Z

In #145310, I removed this line, which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (#145534). I could swear I tested this in the PR, but somehow I missed it.

Instead of keeping the original returned stage, I made it more explicit by returning the actually used build_compiler from the Rustc step, and then use that in the Assemble step.

The changes to RustcLink were needed to fix ui-fulldeps, which apparently build a stage3 rustc, because I haven't fixed the test steps yet 😅

Hopefully we might be able to remove RustcLink if the approach from #144252 will work.

Should fix #145534.

r? @jieyouxu

Kobzol · 2025-08-18T09:52:43Z

Ok I realize another error now (which is already fixed in this PR). Before #145310, bootstrap used to say "uplifting stage1 rustc to stage3", but that's clearly bogus, it was actually uplifting the stage2 compiler. But I trusted the message and implemented uplifting of stage 1 in #145310, which is wrong (because of the ABI difference).

jieyouxu · 2025-08-18T10:12:27Z

my condolences on the extra space

jieyouxu

This was not obvious 😭 Thanks, r=me after comment fix.

jieyouxu · 2025-08-18T12:15:46Z

src/bootstrap/src/core/build_steps/compile.rs


-/// `RustcLink` copies all of the rlibs from the rustc build into the previous stage's sysroot.
+/// `RustcLink` copies compiler rlibs from a rustc build into a compiler sysroot.
+/// It works with (potentially up to) three compilers:


Remark: 😰

src/bootstrap/src/core/build_steps/compile.rs

jieyouxu · 2025-08-18T12:17:49Z

@rustbot author

Kobzol · 2025-08-18T20:09:47Z

@bors r=jieyouxu

bors · 2025-08-18T20:09:49Z

📌 Commit 4c21251 has been approved by jieyouxu

It is now in the queue for this repository.

Fix uplifting in `Assemble` step In rust-lang#145310, I removed [this line](https://github.com/rust-lang/rust/pull/145310/files#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L2109), which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (rust-lang#145534). I could swear I tested this in the PR, but somehow I missed it. Instead of keeping the original returned stage, I made it more explicit by returning the actually used `build_compiler` from the `Rustc` step, and then use that in the `Assemble` step. The changes to `RustcLink` were needed to fix `ui-fulldeps`, which apparently build a stage3 rustc, because I haven't fixed the test steps yet 😅 Hopefully we might be able to remove `RustcLink` if the approach from rust-lang#144252 will work. Should fix rust-lang#145534. r? `@jieyouxu`

Rollup of 19 pull requests Successful merges: - #140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`) - #141744 (Stabilize `ip_from`) - #142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`) - #142871 (Trivial improve doc for transpose ) - #144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std) - #144476 (rustdoc-search: search backend with partitioned suffix tree) - #144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases) - #144804 (Don't warn on never to any `as` casts as unreachable) - #144960 ([RTE-513] Ignore sleep_until test on SGX) - #145013 (overhaul `&mut` suggestions in borrowck errors) - #145041 (rework GAT borrowck limitation error) - #145243 (take attr style into account in diagnostics) - #145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths) - #145432 (cg_llvm: Small cleanups to `owned_target_machine`) - #145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings) - #145557 (Fix uplifting in `Assemble` step) - #145563 (Remove the `From` derive macro from prelude) - #145565 (Improve context of bootstrap errors in CI) - #145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance) Failed merges: - #145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one) - #145573 (Add an experimental unsafe(force_target_feature) attribute.) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #145557 - Kobzol:rustc-link-fix, r=jieyouxu Fix uplifting in `Assemble` step In #145310, I removed [this line](https://github.com/rust-lang/rust/pull/145310/files#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L2109), which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (#145534). I could swear I tested this in the PR, but somehow I missed it. Instead of keeping the original returned stage, I made it more explicit by returning the actually used `build_compiler` from the `Rustc` step, and then use that in the `Assemble` step. The changes to `RustcLink` were needed to fix `ui-fulldeps`, which apparently build a stage3 rustc, because I haven't fixed the test steps yet 😅 Hopefully we might be able to remove `RustcLink` if the approach from #144252 will work. Should fix #145534. r? ``@jieyouxu``

Fix rustc uplifting (take two) The rustc uplifting logic is really annoying.. #145557 was not enough to fix it. Consider #145534 (comment): in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working). Currently, a stage3 cross-compiled build of rustc works like this: 1) stage0 (host) -> stage1 (host) 2) stage1 (host) -> stage2 (host) 3) stage2 (host) -> stage3 (target) The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken. I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time. So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue. Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds. Fixes #145534. r? `@jieyouxu`

Fix rustc uplifting (take two) The rustc uplifting logic is really annoying.. rust-lang/rust#145557 was not enough to fix it. Consider rust-lang/rust#145534 (comment): in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working). Currently, a stage3 cross-compiled build of rustc works like this: 1) stage0 (host) -> stage1 (host) 2) stage1 (host) -> stage2 (host) 3) stage2 (host) -> stage3 (target) The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken. I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time. So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue. Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds. Fixes rust-lang/rust#145534. r? `@jieyouxu`

Rollup of 19 pull requests Successful merges: - rust-lang/rust#140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`) - rust-lang/rust#141744 (Stabilize `ip_from`) - rust-lang/rust#142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`) - rust-lang/rust#142871 (Trivial improve doc for transpose ) - rust-lang/rust#144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std) - rust-lang/rust#144476 (rustdoc-search: search backend with partitioned suffix tree) - rust-lang/rust#144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases) - rust-lang/rust#144804 (Don't warn on never to any `as` casts as unreachable) - rust-lang/rust#144960 ([RTE-513] Ignore sleep_until test on SGX) - rust-lang/rust#145013 (overhaul `&mut` suggestions in borrowck errors) - rust-lang/rust#145041 (rework GAT borrowck limitation error) - rust-lang/rust#145243 (take attr style into account in diagnostics) - rust-lang/rust#145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths) - rust-lang/rust#145432 (cg_llvm: Small cleanups to `owned_target_machine`) - rust-lang/rust#145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings) - rust-lang/rust#145557 (Fix uplifting in `Assemble` step) - rust-lang/rust#145563 (Remove the `From` derive macro from prelude) - rust-lang/rust#145565 (Improve context of bootstrap errors in CI) - rust-lang/rust#145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance) Failed merges: - rust-lang/rust#145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one) - rust-lang/rust#145573 (Add an experimental unsafe(force_target_feature) attribute.) r? `@ghost` `@rustbot` modify labels: rollup

Fix rustc uplifting (take two) The rustc uplifting logic is really annoying.. rust-lang/rust#145557 was not enough to fix it. Consider rust-lang/rust#145534 (comment): in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working). Currently, a stage3 cross-compiled build of rustc works like this: 1) stage0 (host) -> stage1 (host) 2) stage1 (host) -> stage2 (host) 3) stage2 (host) -> stage3 (target) The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken. I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time. So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue. Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds. Fixes rust-lang/rust#145534. r? `@jieyouxu`

rustbot assigned jieyouxu Aug 18, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Aug 18, 2025

Kobzol force-pushed the rustc-link-fix branch from 0e6a966 to a9f3ee7 Compare August 18, 2025 09:40

This comment has been minimized.

Sign in to view

Kobzol force-pushed the rustc-link-fix branch from a9f3ee7 to 51be850 Compare August 18, 2025 11:15

jieyouxu approved these changes Aug 18, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 18, 2025

Fix uplifting in Assemble step

4c21251

Kobzol force-pushed the rustc-link-fix branch from 51be850 to 4c21251 Compare August 18, 2025 20:09

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 18, 2025

Zalathar mentioned this pull request Aug 19, 2025

Rollup of 19 pull requests #145589

Merged

bors merged commit cf2f50e into rust-lang:master Aug 19, 2025
10 checks passed

rustbot added this to the 1.91.0 milestone Aug 19, 2025

Kobzol deleted the rustc-link-fix branch August 19, 2025 11:59

Kobzol mentioned this pull request Aug 20, 2025

Fix rustc uplifting (take two) #145645

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix uplifting in `Assemble` step#145557

Fix uplifting in `Assemble` step#145557
bors merged 1 commit intorust-lang:masterfrom
Kobzol:rustc-link-fix

Kobzol commented Aug 18, 2025 •

edited

Loading

Uh oh!

Kobzol commented Aug 18, 2025 •

edited

Loading

Uh oh!

This comment has been minimized.

jieyouxu commented Aug 18, 2025

Uh oh!

jieyouxu left a comment

Uh oh!

jieyouxu Aug 18, 2025

Uh oh!

Uh oh!

jieyouxu commented Aug 18, 2025

Uh oh!

Kobzol commented Aug 18, 2025

Uh oh!

bors commented Aug 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

Kobzol commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

jieyouxu commented Aug 18, 2025

Uh oh!

jieyouxu left a comment

Choose a reason for hiding this comment

Uh oh!

jieyouxu Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jieyouxu commented Aug 18, 2025

Uh oh!

Kobzol commented Aug 18, 2025

Uh oh!

bors commented Aug 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Kobzol commented Aug 18, 2025 •

edited

Loading

Kobzol commented Aug 18, 2025 •

edited

Loading