Tracking Issue for abort_unwind

[CAD97]

Feature gate: #![feature(abort_unwind)]

This is a tracking issue for core::panic::abort_unwind.

abort_unwind is similar to catch_unwind, except that it aborts the process if it unwinds instead of catching the unwind. Prior to the abort, the panic hook is called in the same way that it is for other functions that cannot unwind (e.g. extern "C" fn).

Public API

// in core::panic (and std::panic)

fn abort_unwind<F: FnOnce() -> R, R>(f: F) -> R;

Steps / History

• ACP: ACP: panic::abort_unwind libs-team#441
• Implementation: Add core::panic::abort_unwind #130339
• Final naming (abort_on_unwind)?
• Improve documentation (add example)?
• Expose a better fn abort() -> ! in core?
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[ChrisDenton]

Does this not imply we should have abort in core?

[CAD97]

As was mentioned on the ACP, it would indeed be unfortunate if abort_unwind(|| panic!()) became the pseudo canonical way to abort without std. (I do think exposing a way to create non-unwinding panics would be a good idea.) However, note that this API doesn't enable anything that wasn't already possible in user code without std—while the implementation is written using #[rustc_nounwind], extern "C" stably has that same effect now, as of 1.81.

[the8472]

Bikeshed: I think abort_on_unwind would be a better name. Otherwise it sounds like some somewhat nonsense operation that first unwinds and then aborts.

[CAD97]

abort_unwind is named like catch_unwind, but it's also named like resume_unwind, so I can see expecting abort_unwind to instead be

fn abort_unwind(payload: Box<dyn Any + Send>) {
    abort_on_unwind(|| drop(payload))
    // or aborts with "unwind in cleanup"
}

for handling the catch_unwind footgun where dropping the panic payload can itself unwind. Or some magic to abort an in-progress unwind.

I'm mostly ambivalent on this matter and the implementation PR is approved already, so I'll leave the name to let libs-api stew on it for now.

[RalfJung]

I agree the name is confusing, I first thought this would abort unwinding (e.g., being in the same category as resume_unwind) -- whatever that means.