Avoid more rustc rebuilds in cross-compilation scenarios

[Kobzol]

This is a continuation of #145874.

It adds a compiler_for_std function, which is a slimmed down version of compiler_for, which is much simpler, and designed to be used only for the standard library.

The build, dist and doc steps somtimes work with a stage2 std for a given target. That currently requires building a stage2 host compiler. However, if we uplift the stage1 libstd anyway, that is wasteful, in particular when we are cross-compiling.

The last two commits progressively make the stage 2 host rustc build avoidance more and more aggressive. I think that if we decide that it is fine to ship stage1 libstd everywhere, then it makes sense to go all the way.

When we ship stuff, we always build it with the stage 1 compiler (e.g. we ship stage 2 rustc which is built with stage 1 rustc). Libstd is the only component where stage N is built with the stage N compiler. So I think that shipping stage 1 libstd is "enough", and we could thus optimize what gets built on CI.

r? @jieyouxu

[bors]

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

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Thanks

View changes since this review

[jieyouxu]

@bors r+ rollup=never

[bors]

📌 Commit 6864a5b has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6864a5b with merge db3fd47...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing db3fd47 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 41f2b6b (parent) -> db3fd47 (this PR)

Test differences

Show 1 test diff

Stage 0

• core::builder::tests::snapshot::dist_rustc_docs: [missing] -> pass (J0)

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 db3fd4708c3916bbc59b81ff7d3f6e19d11820c7 --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-android: 2598.1s -> 1528.5s (-41.2%)
2. dist-various-2: 3262.8s -> 2167.7s (-33.6%)
3. dist-aarch64-linux: 8376.8s -> 6248.3s (-25.4%)
4. dist-apple-various: 5071.0s -> 3912.2s (-22.9%)
5. dist-loongarch64-linux: 6615.3s -> 5265.2s (-20.4%)
6. aarch64-apple: 6205.7s -> 5097.8s (-17.9%)
7. dist-x86_64-apple: 6911.7s -> 8106.1s (17.3%)
8. x86_64-rust-for-linux: 3112.1s -> 2617.6s (-15.9%)
9. test-various: 5191.4s -> 4592.5s (-11.5%)
10. aarch64-gnu-debug: 4697.8s -> 4190.1s (-10.8%)

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 (db3fd47): 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.5%	[0.5%, 0.5%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.8%)

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

	mean	range	count
Regressions ❌ (primary)	2.8%	[1.2%, 4.3%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.8%	[1.2%, 4.3%]	2

Cycles

Results (secondary 2.4%)

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.4%	[2.2%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 466.755s -> 467.612s (0.18%)
Artifact size: 388.52 MiB -> 388.52 MiB (-0.00%)