Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow building stage1+ std with panic=abort #119669

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Allow building stage1+ std with panic=abort #119669

wants to merge 1 commit into from
+32 −6

Conversation

clubby789
Copy link
Contributor

Initial approach to #84766

This adds a rust.panic-strategy-std option to bootstrap, which controls how stage1+ std is built. I decided not to apply it to stage 0 std, otherwise I'd need to make the bootstrap compiler inject the correct panic runtime to build stage1 correctly.

Draft for now as this I'm not sure about the strategy, and only stage0 and 1 can be built with this option right now.

(All library changes are just fixing warnings that occur when building std with panic_immediate_abort)

@rustbot
Copy link
Collaborator

rustbot commented Jan 6, 2024

r? @albertlarsan68

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added 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-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 6, 2024
@saethlin
Copy link
Member

saethlin commented Jan 6, 2024

I'm very wary of the proliferation and complexity of the cfg(feature = "panic_immediate_abort") in the library. I don't really have any confidence in our ability to keep the feature working because it has no tests: #118393 I tried to follow my own directions in there to create a test and I got too frustrated by the complexity of the run-make tests which I think is what one would use here, and I gave up.

saethlin
saethlin reviewed Jan 6, 2024
View reviewed changes
src/bootstrap/src/lib.rs Outdated
let mut features = " panic-unwind".to_string();
fn std_features(&self, target: TargetSelection, stage: u32) -> String {
let mut features = match self.config.rust_panic_strategy_std {
PanicStrategy::Abort if stage > 0 => " panic_immediate_abort",
Copy link
Member

@saethlin saethlin Jan 6, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think that we should be doing this, aborting panics are not the same as panic_immediate_abort; aborting panics are effectively just panics that don't unwind the stack. They still do all the formatting of the panic message and print a backtrace. Immediate-abort panics don't do any formatting and just call core::intrinsics::abort.

I have thought about ways to make immediate-abort a proper panic strategy, and one could do that albiet poorly by changing the lowering of calls to the panic lang items when the feature is enabled. That doesn't fix all the cfgs which are most of the maintenance burden.

@saethlin
Copy link
Member

saethlin commented Jan 6, 2024

I'm very happy to see someone working on making our support for panic modes other than unwind better; I don't want to stifle making progress by advising too much caution but I do think the fact that we default to unwind and assume unwinding in so many places has laid a lot of traps that it will take time to fix.

@clubby789
Copy link
Contributor Author

clubby789 commented Jan 9, 2024 •
edited

Given that if std uses panic=abort, anything depending on it will also need that, so I've moved the flag to be set for all Cargo invocations (and removed the panic_immediate_abort) stuff.
To get testing to work, I guess for a start I'll need to also set -Zpanic_abort_tests for test crates, and pass the panic configuration through to compiletest so it can build with panic=abort and ignore tests requiring unwinding.
We also need to avoid building proc-macro crates and tests that depend on them

@albertlarsan68
Copy link
Member

Is this PR waiting on my review, or is more implementation/bug hunting needed?

@clubby789
Copy link
Contributor Author

More implementation needed - I need to figure out an approach for the above

@clubby789 clubby789 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 23, 2024
@bors
Copy link
Contributor

bors commented Feb 11, 2024

☔ The latest upstream changes (presumably #120803) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC
Copy link
Member

@clubby789 any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@saethlin saethlin saethlin left review comments

Assignees

@albertlarsan68 albertlarsan68

Labels
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-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
6 participants
@clubby789 @rustbot @saethlin @albertlarsan68 @bors @Dylan-DPC