Skip to content

Rollup of 3 pull requests#153550

Closed
jhpratt wants to merge 7 commits intorust-lang:mainfrom
jhpratt:rollup-3RAVRoN
Closed

Rollup of 3 pull requests#153550
jhpratt wants to merge 7 commits intorust-lang:mainfrom
jhpratt:rollup-3RAVRoN

Conversation

@jhpratt
Copy link
Member

@jhpratt jhpratt commented Mar 7, 2026

Successful merges:

r? @ghost

Create a similar rollup

dpaoliello and others added 7 commits February 27, 2026 14:53
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
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Mar 7, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 7, 2026
@jhpratt
Copy link
Member Author

jhpratt commented Mar 7, 2026

@bors r+ rollup=never p=5

@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 7, 2026

📌 Commit 774a4a8 has been approved by jhpratt

It is now in the queue for this repository.

@rust-bors 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 7, 2026
@Zalathar
Copy link
Member

Zalathar commented Mar 8, 2026

Yielding to a slightly newer/larger rollup:

@Zalathar Zalathar closed this Mar 8, 2026
@rust-bors rust-bors bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 8, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 8, 2026

This pull request was unapproved due to being closed.

@rust-bors rust-bors bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 8, 2026
@jhpratt jhpratt deleted the rollup-3RAVRoN branch March 8, 2026 03:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants