Fix rustc uplifting (take two)

[Kobzol]

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

[jieyouxu]

These stage numbers are getting out of hand /s

More seriously, I'm okay with this current approach as a temporary measure. Uplifting really is very iffy.

[jieyouxu]

Going to jump the queue here to fix broken cross builds.
@bors r+ rollup=never p=10

[bors]

📌 Commit f254075 has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit f254075 with merge e8a792d...

[bors]

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

[github-actions]

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 bec7474 (parent) -> e8a792d (this PR)

Test differences

Show 6 test diffs

Stage 0

• core::builder::tests::snapshot::build_compiler_stage_3: [missing] -> pass (J0)
• core::builder::tests::snapshot::build_compiler_stage_3_cross: [missing] -> pass (J0)
• core::builder::tests::snapshot::build_compiler_stage_3_cross_full_bootstrap: [missing] -> pass (J0)
• core::builder::tests::snapshot::build_compiler_stage_3_full_bootstrap: [missing] -> pass (J0)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-19-2, aarch64-msvc-2, i686-gnu-2, i686-gnu-nopt-2, i686-msvc-2, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-2, x86_64-msvc-2

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard e8a792daf500b5ff8097896ddb6cc037abe92487 --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. aarch64-apple: 6799.1s -> 5530.4s (-18.7%)
2. dist-x86_64-apple: 8506.4s -> 7153.0s (-15.9%)
3. x86_64-rust-for-linux: 3090.8s -> 2632.0s (-14.8%)
4. x86_64-gnu-llvm-19: 2919.3s -> 2500.1s (-14.4%)
5. pr-check-1: 1588.0s -> 1396.0s (-12.1%)
6. aarch64-gnu: 7442.9s -> 6585.3s (-11.5%)
7. x86_64-gnu-tools: 3839.8s -> 3409.6s (-11.2%)
8. x86_64-gnu-stable: 7671.9s -> 6837.1s (-10.9%)
9. aarch64-gnu-llvm-19-2: 2437.5s -> 2177.7s (-10.7%)
10. i686-gnu-nopt-1: 8354.4s -> 7472.3s (-10.6%)

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]

Finished benchmarking commit (e8a792d): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.2%, 0.4%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (secondary -0.2%)

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)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 471.629s -> 471.66s (0.01%)
Artifact size: 378.28 MiB -> 378.20 MiB (-0.02%)