Stabilise abort_immediate

[nia-e]

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

Closes #154601 by stabilising the feature. Explicitly do not promise any particular behaviour beyond aborting in some nonspecific violent fashion.

The ACP for the relevant feature was accepted 2 years ago and the feature has been on nightly for 5 months with the only apparent concerns being related to naming and the possibility of having a version of abort in core that guarantees calling the system abort if available, but such an implementation is blocked on EIIs and there is merit to offering this in parallel as well. Additionally, the nonspecific semantics of abort_immediate let us change its behaviour to opportunistically call abort in the future if so desired.

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey

[ChrisDenton]

It would probably be good to replace uses of intrinsics::abort in core/alloc with abort_immediate before stabilization.

[clarfonthey]

Only potential confusion is panic=immediate-abort which does not relate to this at all. (#147286)

[nia-e]

It would probably be good to replace uses of intrinsics::abort in core/alloc with abort_immediate before stabilization.

happy to roll that into this pr, since this just wraps the intrinsic

Only potential confusion is panic=immediate-abort which does not relate to this at all. (#147286)

hmm, fair. in that case still i'd let the team rule on the preferred naming here

[clarfonthey]

Yeah, fine with the team deciding on the naming, but I think immediate-abort and abort_immediate are close enough and distinct enough that one of them should change, and I'm inclined to say it's this one that should change.

Bad suggestion: abort_by_any_means_necessary

[maxdexh]

abort_immediate has the nice property of telling you in the name that you should be using abort instead if you can. Even if it's a little questionable to call it an abort (though it could be implemented as one), I think abort_* is a very practical name (compared to the suggestion of crash)

[ChrisDenton]

I can't really think of anything much better. The most important property is that it tries to terminate the process without doing anything else (if possible) or at least a minimal amount of other things.

The only thing I can think of is something like abort_critical. Which I feel has a sense urgency about it. But I'm fine with abort_immediate to be quite honest.

[clarfonthey]

I guess that it doesn't technically matter if the two names don't have the same exact semantics because the idea of immediately aborting is the same in both cases.

And the rearranged words helps to indicate that they might be different.

[hanna-kruppe]

Additionally, the nonspecific semantics of abort_immediate let us change its behaviour to opportunistically call abort in the future if so desired.

I think it would be better if we could get consensus to not do that, i.e., keep abort_immediate as it was originally conceived and plan to call the "maybe calls std::process::abort()" version something different if/when it's added. There are places where you want to exit immediately with as little chance of other code running for safety, and/or want to minimize code size overhead. So there's a need for a function that promises to do just that.

For example, glibc abort() until 2.26 did stdio buffer flushing, risking deadlocks (we still support glibc 2.17 last I checked). And on all POSIX platforms, abort() raises SIGABRT and thus can run a signal handler, which you can readily install and do silly things in. Technically some abort_immediate impls like x86 ud2 can also be caught as SIGILL, but I think the risk for that is significantly lower (e.g., signal-hook-registry refuses to install SIGILL handlers in its main API, and I hope people writing SIGILL handlers are more careful about not doing anything on the canonical "crash ASAP" operation).

[RalfJung]

IMO it is UB to install signal handlers that do anything "weird", so the SIGABRT argument is not very convincing to me. But I agree with the rest.

[xtqqczze]

The naming could be confusing since std::process::abort is already documented to "immediately terminate the current process".

[hanna-kruppe]

IMO it is UB to install signal handlers that do anything "weird", so the SIGABRT argument is not very convincing to me. But I agree with the rest.

It's certainly ill-advised to do anything non-trivial, and in practice almost every signal handler I've ever seen is not quite async-signal-safe and thus UB anyway. But having a SIGABRT handler at all isn't too weird if you e.g. want to make sure you restore terminal state on exit.

And more generally: async-signal-safe code has to be able to abort somehow (panic isn't AS-safe). While abort() is AS-safe, the reentrance via another signal handler still seems like a huge footgun.

[RalfJung]

async-signal-safety is a necessary condition for code in such a signal handler, but not a sufficient one. The rest of the program generally gets to assume that signal handlers don't interfere with the normal program execution.

[clarfonthey]

This paragraph feels a bit weird to me since it tries to define what an interrupt is to people operating on bare-metal targets as if they've only worked with OS targets before.

Not exactly sure what a better version would look like, but this feels very strange.

View changes since the review

[clarfonthey]

As mentioned in the signal handling discussion, we probably should just put our foot down somewhat on this and say that you generally should not try and intercept whatever signal gets raised by this, and instead rely on the regular abort if you want predictable mechanics.

View changes since the review

[PoignardAzur]

How about abort_raw or abort_minimal?

[maxdexh]

abort_yesterday