Rollup of 4 pull requests by Zalathar · Pull Request #153552 · rust-lang/rust

Zalathar · 2026-03-08T03:01:36Z

Successful merges:

[win] Fix truncated unwinds for Arm64 Windows #153202 ([win] Fix truncated unwinds for Arm64 Windows)
coretest in miri: fix using unstable libtest features #153437 (coretest in miri: fix using unstable libtest features)
Always use the ThinLTO pipeline for pre-link optimizations #153446 (Always use the ThinLTO pipeline for pre-link optimizations)
add test for closure precedence in TokenStreams #153548 (add test for closure precedence in TokenStreams)

When using cargo this was already effectively done for all dependencies as cargo passes -Clinker-plugin-lto without -Clto=fat/thin. -Clinker-plugin-lto assumes that ThinLTO will be used. The ThinLTO pre-link pipeline is faster than the fat LTO one. And according to the benchmarks in [1] there is barely any runtime performance difference between executables that used fat LTO with the fat vs ThinLTO pre-link pipeline. [1]: https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774

This reverts commit 30d7ed4. It should not be needed any more.

[win] Fix truncated unwinds for Arm64 Windows Panic backtraces on ARM64 Windows are truncated because Rust's LLVM configuration sets `NoTrapAfterNoreturn = true`, which suppresses the generation of `brk #0x1` (trap) instructions after calls to `noreturn` functions. Without this trap instruction, the return address from a `noreturn` call points past the end of the calling function into an unrelated function, causing `RtlLookupFunctionEntry` to return the wrong unwind information, which terminates the stack walk prematurely. In general, `NoTrapAfterNoreturn = true` is recommended against for Windows, since we have seen security vulnerabilities in the past where an attacker has managed to return from a noreturn function, or the function wasn't actually noereturn, resulting in executing whatever was after the call. This change disables setting `NoTrapAfterNoreturn = true` for Windows. Fixes rust-lang#140489

…cuviper coretest in miri: fix using unstable libtest features Alternative (IMO preferable) to rust-lang#153369. Also reverts that PR.

…viper Always use the ThinLTO pipeline for pre-link optimizations When using cargo this was already effectively done for all dependencies as cargo passes -Clinker-plugin-lto without -Clto=fat/thin. -Clinker-plugin-lto assumes that ThinLTO will be used. The ThinLTO pre-link pipeline is faster than the fat LTO one. And according to the benchmarks in [^1] there is barely any runtime performance difference between executables that used fat LTO with the fat vs ThinLTO pre-link pipeline. This also helps avoid having yet another code path if we want to support Unified LTO (that is a single bitcode file that supports being used for both fat LTO and ThinLTO when using linker plugin LTO, we already support it when rustc does LTO as ThinLTO bitcode is enough of a superset of fat LTO bitcode that it happens to work by accident if you don't explicitly have a check preventing mixing of them for the current set of LTO features that rustc exposes.) I'm currently still investigating if rustc would benefit from Unified LTO and how exactly to integrate it. [^1]: https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774

add test for closure precedence in `TokenStream`s A test for a regression found by the rust-lang#151830 crater run in several different crates.

Zalathar · 2026-03-08T03:01:59Z

Rollup of everything.

@bors r+ rollup=never p=5

rust-bors · 2026-03-08T03:02:02Z

📌 Commit 9886a13 has been approved by Zalathar

It is now in the queue for this repository.

rust-bors · 2026-03-08T07:03:03Z

☀️ Test successful - CI
Approved by: Zalathar
Duration: 3h 17m 54s
Pushing c3d0140 to main...

rust-timer · 2026-03-08T07:04:11Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#153202	[win] Fix truncated unwinds for Arm64 Windows	`117729d69e7aceaf9b0ba13f7b18a3e89e7d5051` (link)
#153437	coretest in miri: fix using unstable libtest features	`b252b4ce9d89ee38a6be54726609b9e50c8a7a11` (link)
#153446	Always use the ThinLTO pipeline for pre-link optimizations	`9f367f0073ef6d37017665e73b614a8f8951f5d5` (link)
#153548	add test for closure precedence in `TokenStream`s	`9219d8759b8d24c1b0ffeb5a231d19781aaf6b44` (link)

previous master: 052b9c23da

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

github-actions · 2026-03-08T07:05:41Z

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 052b9c2 (parent) -> c3d0140 (this PR)

Test differences

Show 5 test diffs

Stage 1

[ui] tests/ui/proc-macro/identity-closure-preserving.rs: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/proc-macro/identity-closure-preserving.rs: [missing] -> pass (J0)

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

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard c3d014032f39a252387ca7c4fe4039c1b7c01eb4 --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

aarch64-apple: 4h 6m -> 3h 12m (-22.0%)
dist-aarch64-apple: 2h 2m -> 2h 20m (+14.4%)
x86_64-gnu-llvm-20-2: 1h 38m -> 1h 27m (-11.1%)
arm-android: 1h 36m -> 1h 46m (+9.8%)
x86_64-gnu-llvm-21-3: 2h 1m -> 1h 49m (-9.7%)
x86_64-gnu-miri: 1h 25m -> 1h 34m (+9.7%)
dist-aarch64-msvc: 1h 40m -> 1h 49m (+8.9%)
x86_64-gnu-llvm-20-3: 2h -> 1h 50m (-8.5%)
dist-x86_64-msvc-alt: 2h 30m -> 2h 42m (+8.2%)
i686-gnu-nopt-1: 2h 10m -> 2h 20m (+7.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 · 2026-03-08T07:43:38Z

Finished benchmarking commit (c3d0140): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	-2.3%	[-2.5%, -2.2%]	4
Improvements ✅ (secondary)	-0.8%	[-0.8%, -0.8%]	1
All ❌✅ (primary)	-2.3%	[-2.5%, -2.2%]	4

Max RSS (memory usage)

Results (primary 1.1%, secondary 2.3%)

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

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

Cycles

Results (primary -2.5%, secondary 6.6%)

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

Binary size

Results (primary -0.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)	-0.4%	[-0.4%, -0.3%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-0.4%, -0.3%]	4

Bootstrap: 477.657s -> 481.476s (0.80%)
Artifact size: 395.01 MiB -> 397.01 MiB (0.51%)

Zalathar · 2026-03-08T07:52:36Z

Perf improvements match the ones in Always use the ThinLTO pipeline for pre-link optimizations #153446 (comment).

Kobzol · 2026-03-10T07:07:15Z

The eza win was caused by #153446, yeah. The coercions tiny loss swung back in the next PR.

@rustbot label: +perf-regression-triaged

dpaoliello and others added 9 commits February 27, 2026 14:53

[win] Fix truncated unwinds for Arm64 Windows

614bac5

Revert "library/test: always enable unstable features for miri"

4d31406

This reverts commit 30d7ed4. It should not be needed any more.

coretest in miri: fix using unstable libtest features

6b7dbff

add test for closure precedence in TokenStreams

1ff7ed5

Rollup merge of rust-lang#153437 - RalfJung:miri-libtest-unstable, r=…

a508c47

…cuviper coretest in miri: fix using unstable libtest features Alternative (IMO preferable) to rust-lang#153369. Also reverts that PR.

Rollup merge of rust-lang#153548 - cyrgani:closuretest, r=JohnTitor

9886a13

add test for closure precedence in `TokenStream`s A test for a regression found by the rust-lang#151830 crater run in several different crates.

rust-bors bot added the rollup A PR which is a rollup label Mar 8, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 8, 2026

Zalathar mentioned this pull request Mar 8, 2026

Rollup of 3 pull requests #153550

Closed

This comment has been minimized.

Sign in to view

rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 8, 2026

rust-bors bot merged commit c3d0140 into rust-lang:main Mar 8, 2026
12 checks passed

rustbot added this to the 1.96.0 milestone Mar 8, 2026

Zalathar deleted the rollup-MALCpPD branch March 8, 2026 07:19

rustbot added the perf-regression Performance regression. label Mar 8, 2026

rustbot added the perf-regression-triaged The performance regression has been triaged. label Mar 10, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rollup of 4 pull requests#153552

Rollup of 4 pull requests#153552
rust-bors[bot] merged 9 commits intorust-lang:mainfrom
Zalathar:rollup-MALCpPD

Zalathar commented Mar 8, 2026

Uh oh!

Zalathar commented Mar 8, 2026

Uh oh!

rust-bors bot commented Mar 8, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 8, 2026

Uh oh!

Uh oh!

rust-timer commented Mar 8, 2026

Uh oh!

github-actions bot commented Mar 8, 2026

Stage 1

Stage 2

Uh oh!

rust-timer commented Mar 8, 2026

Uh oh!

Zalathar commented Mar 8, 2026 •

edited

Loading

Uh oh!

Kobzol commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Uh oh!

Conversation

Zalathar commented Mar 8, 2026

Uh oh!

Zalathar commented Mar 8, 2026

Uh oh!

rust-bors bot commented Mar 8, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 8, 2026

Uh oh!

Uh oh!

rust-timer commented Mar 8, 2026

Uh oh!

github-actions bot commented Mar 8, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Mar 8, 2026

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Zalathar commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Zalathar commented Mar 8, 2026 •

edited

Loading