bump bootstrap compiler to 1.93 beta

[BoxyUwU]

r? release

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

The Miri subtree was changed

cc @rust-lang/miri

[BoxyUwU]

r? mark-simulacrum

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 8995537 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors rollup=never

[jieyouxu]

@bors p=5 (just to get the bootstrap compiler bump done)

[bors]

⌛ Testing commit 8995537 with merge 7eae21d...

[bors]

💥 Test timed out

[Zalathar]

@bors retry (timeout)

[jieyouxu]

EDIT: also, I think there's like 4 cfg(bootstrap)/cfg(not(bootstrap)) in rustc_fluent_macros too, I'm seeing warnings for them locally?

[jieyouxu]

Ah. So, beta rustdoc currently is ICEing on in-tree rustc_mir_build likely due to #148617-adjacent reasons. It's possible to temporarily unblock this bootstrap bump by intentionally regressing the macro-expansion buttons in compiler docs via --generate-macro-expansion in doc::Rustc's

rust/src/bootstrap/src/core/build_steps/doc.rs

Line 935 in 526a91c

cargo.rustdocflag("--generate-macro-expansion");

$ git diff src/bootstrap/src/core/build_steps/doc.rs
diff --git a/src/bootstrap/src/core/build_steps/doc.rs b/src/bootstrap/src/core/build_steps/doc.rs
index fa36a6471ca..bf3de56cd02 100644
--- a/src/bootstrap/src/core/build_steps/doc.rs
+++ b/src/bootstrap/src/core/build_steps/doc.rs
@@ -932,7 +932,7 @@ fn run(self, builder: &Builder<'_>) {
         // see https://github.com/rust-lang/rust/pull/122066#issuecomment-1983049222
         // If there is any bug, please comment out the next line.
         cargo.rustdocflag("--generate-link-to-definition");
-        cargo.rustdocflag("--generate-macro-expansion");
+        //cargo.rustdocflag("--generate-macro-expansion");

         compile::rustc_cargo(builder, &mut cargo, target, &build_compiler, &self.crates);
         cargo.arg("-Zskip-rustdoc-fingerprint");

This locally makes ./x doc compiler/ --stage=1 pass for me. (Note that ./x doc compiler/ --stage=2 passes for me with an in-tree rustdoc, so it seems like only beta rustdoc is ICEing somehow.)

What I don't understand is why. Maybe #148655 wasn't sufficient, somehow? cc @GuillaumeGomez maybe you have any ideas?

EDIT: oh, this is very new:

• Generate macro expansion for rust compiler crates docs #150022
• [rustdoc] Fix invalid handling of field followed by negated macro call #150099

So yeah, we can temporarily revert enabling --generate-macro-expansion to unblock bootstrap bump.

[GuillaumeGomez]

If the fix is included, this bug should be fixed. If it's an issue, please just comment this feature out for the time being.

Is there anything special about about we build compiler docs in this case? (so I can reproduce locally)

[jieyouxu]

Is there anything special about about we build compiler docs in this case? (so I can reproduce locally)

Not specifically that I know of (well, apart from the usual mix of unstable rustdoc flags too). If I'm not mistaken, the failing case is ./x doc compiler --stage=1 where we use a beta rustdoc to build in-tree compiler docs. Locally, I see that ./x doc compiler --stage=2 (in-tree rustdoc on in-tree compiler sources) passes and doesn't ICE.

There's several flags (including unstable ones) we build compiler docs with in

rust/src/bootstrap/src/core/build_steps/doc.rs

Line 925 in 07a5b02

cargo.rustdocflag("--document-private-items");

, some of which are not used for other parts of the codebase. I wonder if it's a convoluted combination of those that triggers an edge case...

EDIT: continuing this conversation over at #t-rustdoc > "Didn't find 'Class::Original' to close" since github is already folding comments. Let's try disabling the flag for now.

[rustbot]

This PR was rebased onto a different main 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.

[cuviper]

Looks like it passed with the revert, so let's try again!

@bors r=Mark-Simulacrum,cuviper

[bors]

📌 Commit b22b343 has been approved by Mark-Simulacrum,cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit b22b343 with merge f51d1bc...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum,cuviper
Pushing f51d1bc to main...

[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 9044e98 (parent) -> f51d1bc (this PR)

Test differences

Show 346 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f51d1bcdc69f9bba47cc1656260ff76e6ff5fba3 --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-aarch64-linux: 6770.2s -> 8837.1s (+30.5%)
2. aarch64-apple: 12113.6s -> 10154.4s (-16.2%)
3. dist-s390x-linux: 4953.0s -> 5672.0s (+14.5%)
4. dist-loongarch64-musl: 5252.9s -> 6012.7s (+14.5%)
5. dist-aarch64-llvm-mingw: 6543.3s -> 5608.3s (-14.3%)
6. x86_64-gnu-llvm-20: 4379.2s -> 4853.1s (+10.8%)
7. dist-x86_64-freebsd: 4690.4s -> 5136.7s (+9.5%)
8. x86_64-gnu-llvm-20-2: 5975.5s -> 5431.1s (-9.1%)
9. armhf-gnu: 5537.4s -> 5040.3s (-9.0%)
10. aarch64-gnu: 7403.7s -> 7996.6s (+8.0%)

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 (f51d1bc): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 1.2%)

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

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

Cycles

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

Binary size

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

Bootstrap: 478.41s -> 480.387s (0.41%)
Artifact size: 390.55 MiB -> 390.53 MiB (-0.00%)