Tracking Issue for abort_immediate (abort in core)

[CAD97]

Feature gate: #![feature(abort_immediate)]

This is a tracking issue for core::process::abort_immediate.

abort_immediate aborts/halts/crashes the process with as little overhead as possible. This exposes intrinsics::abort's behavior to stable. This is also reexported as std::process::abort_immediate.

Public API

// core::process
pub fn abort_immediate() -> !;

// std::process
pub fn abort_immediate() -> !;

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: abort in core libs-team#442
• Implementation: abort in core #154604
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Given we want core::process::abort to opportunistically do std::process::abort if possible and abort_immediate otherwise, do we even want to expose a separate abort_immediate?
• Would another name more clearly communicate intent? Options include process::crash, process::halt, or others.
• Is core::process a reasonable home for this? It will be the first item.

Footnotes

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

[saethlin]

• Would another name more clearly communicate intent? Options include process::crash, process::halt, or others.

I just want to make sure people know I am not strongly in favor of the current naming of panic = "immediate-abort" and I do not want its current name to be used as justification for the name choice here, though of course it makes sense for them to stay in sync. (It would be unfortunate if we end up stuck with this preliminary name) In particular, I am not sure that simply adding "immediate" is clear enough. exit and abort get to lean on existing terminology from other languages (mostly C) and I don't think there is an equivalent for this mechanism.

[CAD97]

Arguably, Win32's TerminateProcess vs __fastfail could be understood as the same kind of difference, but our abort is already __fastfail. (Windows's abort is nonconforming and may run loaded DLL's destructors, so isn't appropriate for Rust.)

[ChrisDenton]

The purely descriptive name would be abort-no-hook or something like that?

[ds84182]

I think process::crash is the most descriptive considering the description in the ACP (immediately executing an illegal instruction).

halt implies an infinite wait loop where things like interrupts and signals can still be serviced. Like a wfi loop on arm. It reliably hangs the thread of execution, keeping all of its resources alive.

[nia-e]

abort_immediate is imo sufficiently descriptive in that it makes it clear what's happening (we're ending the process as quickly as possible). if anything, crash to me sounds like something that would trigger some kind of error logging mechanism via a hook.

I'd also argue this is highly useful to have regardless of there being an opportunistically hook-calling abort in core, since there are cases when the desired behaviour is genuinely "shut everything down asap, don't call anything". my stance would be to stabilise this as-is

[ChrisDenton]

Btw, I would ideally want core::process::abort to use __fastfail on Windows because currently the intrinsic throws an SEH exception rather than immediately aborting whereas __fastfail is more like "shut everything down asap". There was controversy in #149780 about changing the intrinsic itself but changing core::process::abort should not have the same issue.