Bump bootstrap to 1.98 beta

[Mark-Simulacrum]

View all comments

https://forge.rust-lang.org/release/process.html#default-branch-bootstrap-update-and-crater-tuesday

[rustbot]

miri is developed in its own repository. If possible, consider making this change to rust-lang/miri instead.

cc @rust-lang/miri

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

Some changes occurred in integer formatting

cc @tgross35

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, clarfonthey, jhpratt

[jieyouxu]

Thanks
r? me @bors r+ rollup=never

View changes since this review

[rust-bors]

📌 Commit 8e98714 has been approved by jieyouxu

It is now in the queue for this repository.

[JonathanBrouwer]

@bors p=6

[rust-bors]

💔 Test for 2d0b8c5 failed: CI. Failed job:

• auto - dist-i686-msvc (web logs, enhanced plaintext logs)

[JonathanBrouwer]

exit code: 0xc0000017, STATUS_NO_MEMORY

Does this reproduce?
@bors try jobs=dist-i686-msvc

[Mark-Simulacrum]

Hm, not sure if that's sccache to blame necessarily, but we can try disabling sccache on stage0 builds for now. I'll take a look at that later today. This further pushes me towards dropping build dir v2 until it's in a better place though...

[weihanglo]

This further pushes me towards dropping build dir v2 until it's in a better place though...

Agreed, though still want to know if it was sccache or not.

[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.

[Mark-Simulacrum]

@bors try jobs=msvc,mingw

[Mark-Simulacrum]

@bors r=jieyouxu

We're past the previous failure point on those runners (at least by wall clock), so I think we can add it back to the queue.

[rust-bors]

📌 Commit 83aeead has been approved by jieyouxu

It is now in the queue for this repository.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3e1272a (3e1272a3a11fb20b2b531b7464304cf582347fce)
Base parent: 225e91c (225e91c03da22cd4b9792b83c1cfc97967101614)

[rust-bors]

☀️ Test successful - CI
Approved by: jieyouxu
Duration: 3h 24m 56s
Pushing 55b6bd8 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 daf2e5e (parent) -> 55b6bd8 (this PR)

Test differences

Show 6 test diffs

6 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 55b6bd8ecbed23599e966a04508a8a13cbfe90b3 --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. x86_64-gnu-gcc-core-tests: 9m 6s -> 14m 21s (+57.6%)
2. x86_64-gnu-next-trait-solver-polonius: 41m 17s -> 1h 1m (+48.6%)
3. x86_64-gnu-llvm-21: 55m 55s -> 1h 20m (+43.4%)
4. test-various: 1h 34m -> 2h 8m (+36.4%)
5. x86_64-gnu-llvm-21-1: 39m 19s -> 52m 41s (+34.0%)
6. dist-x86_64-linux-alt: 1h 51m -> 2h 21m (+27.0%)
7. x86_64-msvc-2: 2h 27m -> 1h 51m (-24.5%)
8. dist-apple-various: 1h 27m -> 1h 48m (+24.2%)
9. dist-ohos-x86_64: 1h 1m -> 1h 16m (+23.7%)
10. dist-powerpc64-linux-musl: 1h 34m -> 1h 14m (-21.9%)

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 (55b6bd8): 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.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 0.8%)

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)	4.5%	[4.0%, 5.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-3.3%, -2.4%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 1.5%)

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.521s -> 489.277s (-0.25%)
Artifact size: 389.35 MiB -> 389.95 MiB (0.16%)

[ranger-ross]

Hm, not sure if that's sccache to blame necessarily, but we can try disabling sccache on stage0 builds for now. I'll take a look at that later today. This further pushes me towards dropping build dir v2 until it's in a better place though...

I'll look into this to see if it was build-dir v2 related. It probably was.
fwiw, having this enabled in rustc has been really helpful in uncovering bugs in the new layout. (its been pretty difficult to get tester for the new build-dir layout since its a pretty boring feature from an external user's perspective)
My hope is that I can iron out the remaining issues in the near future and reduce these pain points and keep it enabled.

[Mark-Simulacrum]

Sounds good. I think the main pain is that in rust-lang/rust we're not using nightly Cargo so we need to beta-backport fixes -- which is pretty annoying for an unstable feature. I'm not sure if there's any way for us to discover these issues in advance of bootstrap bump, other than someone doing the work to keep such a bump updated and re-running try builds on it periodically throughout the cycle. But that's a good deal of work :(