Auto merge of #145645 - Kobzol:uplift-fix, r=jieyouxu
Fix rustc uplifting (take two)
The rustc uplifting logic is really annoying.. https://github.com/rust-lang/rust/pull/145557 was not enough to fix it.
Consider https://github.com/rust-lang/rust/issues/145534#issuecomment-3201868888: 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`
diff --git a/src/building/bootstrapping/debugging-bootstrap.md b/src/building/bootstrapping/debugging-bootstrap.md
index fb90c0f..93b11c0 100644
--- a/src/building/bootstrapping/debugging-bootstrap.md
+++ b/src/building/bootstrapping/debugging-bootstrap.md
@@ -81,9 +81,11 @@
- If you select a level, all events/spans with an equal or higher priority level will be shown.
2. You can also control the log **target**, e.g. `bootstrap` or `bootstrap::core::config` or a custom target like `CONFIG_HANDLING` or `STEP`.
- Custom targets are used to limit what kinds of spans you are interested in, as the `BOOTSTRAP_TRACING=trace` output can be quite verbose. Currently, you can use the following custom targets:
- - `CONFIG_HANDLING`: show spans related to config handling
- - `STEP`: show all executed steps. Note that executed commands have `info` event level.
- - `COMMAND`: show all executed commands. Note that executed commands have `trace` event level.
+ - `CONFIG_HANDLING`: show spans related to config handling.
+ - `STEP`: show all executed steps. Executed commands have `info` event level.
+ - `COMMAND`: show all executed commands. Executed commands have `trace` event level.
+ - `IO`: show performed I/O operations. Executed commands have `trace` event level.
+ - Note that many I/O are currently not being traced.
You can of course combine them (custom target logs are typically gated behind `TRACE` log level additionally):
