Build-std: panic strategies by Bryanskiy · Pull Request #17185 · rust-lang/cargo

Bryanskiy · 2026-07-06T20:26:59Z

What does this PR try to resolve?

Implementation for rust-lang/wg-cargo-std-aware#29

fixes #7359 (Technically fixed by rust-lang/rust#160007)
fixes #17404

How to test and review this PR?

Commit 1: add panic_abort to mock std and make the panic configuration closer to real std.
Commit 2: add multiple tests.
Commit 3: add test for #17404

Commit 4: remove panic_unwind from roots. With rust-lang/rust#160007 panic runtimes can be loaded like regular transitive dependencies.

Commit 5: implementation for rules described in https://rust-lang.github.io/rfcs/3874-build-std-always.html#panic-strategies. In short, with this change panic_unwind is no longer built when the abort or immediate-abort profiles are used. (previously panic_unwind was always built).

Future steps:

panic-unwind is currently a default feature(it's not in mock-std):

https://github.com/rust-lang/rust/blob/36714a9983d6ba11203d8bb87a1b372247fbcf06/library/sysroot/Cargo.toml#L23

This should be removed to enable this change.

Additional information

Proposal says:

if panic is set to “unwind” then the panic_unwind feature of sysroot will be enabled and -Cpanic=unwind will be passed

but I found that in cargo -Cpanic=unwind is not passed with "unwind" profile:

cargo/src/cargo/core/compiler/mod.rs

Lines 1344 to 1346 in 28fa7f2

    
           if *panic != PanicStrategy::Unwind { 
        
               cmd.arg("-C").arg(format!("panic={}", panic)); 
        
           }

Because rustc in that case uses default which is based on target:

https://github.com/rust-lang/rust/blob/36714a9983d6ba11203d8bb87a1b372247fbcf06/compiler/rustc_session/src/session.rs#L700-L704

Is this a mistake in the RFC, or did I misunderstand something? I have not changed this behavior at the moment for build-std.

cc @adamgemmell

rustbot · 2026-07-06T20:27:05Z

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

Bryanskiy · 2026-07-07T10:02:25Z

@rustbot author (I have to fix CI)

rustbot · 2026-07-07T10:02:29Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

adamgemmell · 2026-07-07T11:04:06Z

Is this a mistake in the RFC, or did I misunderstand something? I have not changed this behavior at the moment for build-std.

I think it probably is... panic = unwind in the profile really just means "use the target default" which is why it uses the default behaviour for rustc as you found.

The RFC also describes what happens when panic isn't set in the profile, which I don't think is possible.

adamgemmell

This looks good, thanks. I appreciate the thorough tests

View changes since this review

adamgemmell · 2026-07-08T16:06:08Z

        crates.insert("alloc");
        crates.insert("proc_macro");
-        crates.insert("panic_unwind");
+        crates.insert("panic_abort");


This should be built by default. The reason the strategies are roots is that rustc won't pick them up unless they're passed in via --extern. We have a section in the build-std=always RFC for this, but it's not next to the other section on panic strategies (sorry!)

rustc loads panic runtimes in a different way to most dependencies, and without looking in the sysroot they will fail to load correctly unless passed in with --extern. rustc will need to be patched to be able to load panic runtimes from -L dependency= paths in line with other transitive dependencies.

This doesn't need to block this PR though as the change to this patch to support that will be quite small, and this function will change a lot in the future anyway when the UI changes.

rust-lang/rust#160007 has landed, so this is now fixed

adamgemmell · 2026-07-08T16:06:42Z

+        // overridden. See `validate_profile_override`.
+        let profile = profiles.base_profile();
+        if profile.panic == PanicStrategy::Unwind {
+            crates.insert("panic_unwind");


Should be enabled via a feature on sysroot eventually once the rustc loading behaviour has been changed. Again, this doesn't need to block this PR.

rust-lang/rust#160007 has landed, so this is now fixed

adamgemmell · 2026-07-08T16:18:31Z

+    let (specs, build_panic_unwind) = {
        // If there is anything looks like needing std, resolve with it.
-        // If not, we assume only `core` maye be needed, as `core the most fundamental crate.
+        // If not, we assume only `core` may be needed, as `core` the most fundamental crate.


nit: "as core is the most fundamental crate"

Bryanskiy · 2026-07-08T18:36:17Z

@rustbot ready (CI is green and Adam sees his concerns as non-blocking)

ehuss · 2026-07-16T18:16:31Z

+        let profile = profiles.base_profile();
+        if profile.panic == PanicStrategy::Unwind {
+            crates.insert("panic_unwind");
+        }


This doesn't seem to handle the situation for cargo test which forces the unwind strategy to be "unwind" even when the strategy is "abort". Thus, when running cargo test, it will end up with the same duplicate lang item problem since it tries to load the wrong unwind.

There's also some complexities when running host tests (proc-macro tests), which I think are also AlwaysUnwind.

I'm a little concerned that trying to deal with these complexities will make this optimization difficult to support. For abort-only targets, the unwind crate should be empty and essentially have no cost.

View changes since the review

Does this test exercise that case? https://github.com/rust-lang/cargo/pull/17185/changes#diff-736f9dbd0f15c0f86f99fa4c395a7639c384213e0d5fe33aadab3f411d53de92R1050

it turned out that the test is incorrect due to:

cargo/tests/testsuite/mock-std/library/test/Cargo.toml

Line 9 in e09f57a

panic_unwind = { path = "../panic_unwind" }

Today I plan to open a PR in rustc to address #17185 (comment) (load panic runtime with -L dependency) and then I'll come back to this concern.

ehuss · 2026-07-16T18:17:27Z

    // those included because we'll never use them anyway.
    std_ws.set_require_optional_deps(false);
-    let specs = {
+    let profiles = Profiles::new(ws, build_config.requested_profile)?;


Just a minor nit, but I worry that this function has the possibility to be expensive to call. Would it be possible to pass it in?

View changes since the review

Done, but this requires moving profile creation before std resolution. Not sure if this is desirable as it might slow down error paths. If necessary I can undo the change.

Bryanskiy · 2026-07-20T09:23:16Z

@rustbot author (need to fix #17185 (comment) and #17185 (comment) first)

weihanglo · 2026-07-30T16:37:40Z

Blocked on rust-lang/rust#160007.

…of the real one

rustbot · 2026-09-02T17:40:17Z

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.

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 6, 2026

rustbot assigned ehuss Jul 6, 2026

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 7, 2026

rustbot added the S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. label Jul 7, 2026

Bryanskiy force-pushed the build-std-panic-strategy-2 branch from 4f5fb5a to 6020f3d Compare July 7, 2026 15:19

This comment has been minimized.

Sign in to view

Bryanskiy force-pushed the build-std-panic-strategy-2 branch from 6020f3d to 6204c2b Compare July 8, 2026 16:21

adamgemmell reviewed Jul 8, 2026

View reviewed changes

Bryanskiy force-pushed the build-std-panic-strategy-2 branch 2 times, most recently from c45cd72 to c603013 Compare July 8, 2026 17:33

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Jul 8, 2026

davidtwco mentioned this pull request Jul 15, 2026

build-std rust-lang/goals#274

Open

10 tasks

ehuss reviewed Jul 16, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 20, 2026

Bryanskiy mentioned this pull request Aug 28, 2026

Windows -Zbuild-std with windows_raw_dylib broken after nightly-2026-08-27 #17404

Open

Bryanskiy added 5 commits September 2, 2026 18:44

test(build-std): Make panic settings in the mock std closer to those …

5709115

…of the real one

test(build-std): add tests for panic strategies

0c151da

test(build-std): test for duplicate lang items with build_std_features

8d9a885

fix(build-std): remove panic_unwind from roots

214bf0a

fix(build-std): compile panic_unwind with respect to user profile

f4371d0

Bryanskiy force-pushed the build-std-panic-strategy-2 branch from c603013 to f4371d0 Compare September 2, 2026 17:40

rustbot added the Command-fetch label Sep 2, 2026

	if *panic != PanicStrategy::Unwind {
	cmd.arg("-C").arg(format!("panic={}", panic));
	}

Uh oh!

Uh oh!

Conversation

Bryanskiy commented Jul 6, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Additional information

Uh oh!

rustbot commented Jul 6, 2026

Uh oh!

Bryanskiy commented Jul 7, 2026

Uh oh!

rustbot commented Jul 7, 2026

Uh oh!

adamgemmell commented Jul 7, 2026

Uh oh!

This comment has been minimized.

adamgemmell left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Bryanskiy commented Jul 8, 2026

Uh oh!

ehuss Jul 16, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehuss Jul 16, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Bryanskiy commented Jul 20, 2026

Uh oh!

weihanglo commented Jul 30, 2026

Uh oh!

rustbot commented Sep 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Bryanskiy commented Jul 6, 2026 •

edited by rustbot

Loading

adamgemmell left a comment •

edited by rustbot

Loading

ehuss Jul 16, 2026 •

edited by rustbot

Loading

ehuss Jul 16, 2026 •

edited by rustbot

Loading