ACP: `panic_abort!`

Proposal

Problem statement

Rust has two kinds of panics: unwinding panics and aborting panics. A panic by panic! will, roughly:

• if -Cpanic=abort, raise an aborting panic;
• if -Cpanic=unwind and the closest catching frame is an unclaimed Rust catch_unwind, claim that frame and raise an unwinding panic;
• else raise a panic that is unspecified whether it is unwinding or aborting.

Although the exact details of how the selection between unwinding and panicking aren't stable, the concept of an aborting panic is user facing. But to deliberately raise one, a developer has to:

• old style: raise a double panic (panicked while panicking / during cleanup); or
• new style: raise a panic in a stack frame that cannot unwind (e.g. extern "C" ABI).

We should provide a way to deliberately raise an aborting panic that is not allowed to unwind (i.e. never runs any drop glue from the raising scope) and is clear in that being developer intent.

Motivating examples or use cases

abort_on_unwind can be used to guard a section of code to cause panics to abort (and should be used if code that could panic is called), but this is sometimes overkill. An example is Arc::clone: if the reference count would overflow, we abort the program. In this specific case we are required to bypass the panic handler for safety in the face of reentrancy (i.e. abort_immediate), but in other cases just raising an aborting panic is better. After all, that's exactly what the runtime does for stack frames that cannot unwind.

Solution sketch

We add a new macro core::panic_abort! just like core::abort! (including edition-reliant behavior) except that it calls core::panicking::panic_nounwind[_fmt] instead of panic[_fmt].

This macro is not added to the prelude; despite being unlikely to conflict with a user defined name with different semantics, we want to still nudge developers towards using potentially-unwinding panics unless they already know they must not unwind. Similarly, we do not add aborting variants of other panicking macros (e.g. assert!); if they are truly needed, they can still be emulated with abort_on_unwind.

Alternatives

Why panic_abort!, when the existing plumbing calls it panic_nounwind?

The _nounwind name is implementation based: PanicInfo::can_unwind returns false and the panicking machinery must not raise an unwind. The _abort name is interface based: we panic as if -Cpanic=abort even when the build was configured differently.

Links and related work

• In https://github.com/rust-lang/libs-team/issues/442, it was noted that a panic_nounwind/panic_abort entry point is desirable independently of abort in core.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

Start with the proposed core::panic_abort! macro and compare the mentioned core::abort! behavior with core::panicking::panic_nounwind and panic_nounwind_fmt. Review abort_on_unwind and the linked libs-team issue, then follow the feature lifecycle; done means the libs-api team has reviewed and approved the proposal for implementation.