abort in core

[CAD97]

Proposal

Problem statement

Contexts without access to std don't have a canonical way to write fn abort() -> !. There should be one.

Motivating examples or use cases

There are multiple ways of aborting the process without std currently, including:

• core::intrinsics::abort (unstable, illegal instruction)
• panic while panicking (panic in a destructor during cleanup)
• panic in extern "C" (panic in a function that cannot unwind)

We should provide a simple way to abort that doesn't rely on directly causing a runtime error.

Solution sketch

// core::process

fn abort() -> !;
fn abort_immediate() -> !;

abort_immediate halts the process as abruptly as possible, usually by executing an illegal instruction. (This is the behavior of the abort intrinsic.)

abort uses a mechanism similar to core panic to raise the more user-friendly std abort when possible, or abort_immediate otherwise. (This will require some new compiler/lang support.)

Alternatives

• Add nothing and stick to the status quo.
• Only add one or the other function.
• Have abort in core always do the intrinsic abort instead of a separate abort_immediate.
• Name abort_immediate differently (crash, halt, etc).
• Provide a way to raise an aborting panic instead.

Links and related work

• ACP #441 introduces abort_unwind, and it's been noted twice already that it probably shouldn't be the nicest way to abort from 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.

[dtolnay]

Yes! I would love for this to be available.

Thank you for brainstorming other options too.

I expect we'll reassess the options after seeing how the abort part of the PR turns out, but this looks great to me to go ahead implementing. I think your intuition is correct that "something like whatever core's panic does" will work as an implementation strategy.

[RalfJung]

abort uses a mechanism similar to core panic to raise the more user-friendly std abort when possible, or abort_immediate otherwise. (This will require some new compiler/lang support.)

What about making it trigger panic_nounwind under the hood? That doesn't require any new support. That also matches what happens when one panics in extern "C".

However that should probably be named something closer to panic_nounwind than abort, since it e.g. triggers the panic hook.

[CAD97]

IMO there needs to be an API which doesn't call the panic hook (thus calling uncontrolled code). panic_nounwind is valuable in its own right for sure, but can and should live alongside options for abort.

Whether panic_nounwind and abort_immediate are sufficient without having “user-friendly” abort in core, I'm still unsure.