Tracking Issue for abort_immediate (abort in core)

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.

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

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.

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.)

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

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.

Rollup merge of rust-lang#154604 - CAD97:abort-immediate, r=scottmcm

Unrolled build for #154604

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

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.

__builtin_trap is the similar C operation to this, so perhaps that's more familiar than the LLVM name.

Added trap as part of #163575

If we're still accepting bikeshed color submissions, I'd call it fault.

@saethlin did you happen to have any alternative names in mind for immediate-abort?

People have suggested trap and crash. In my own mind, I would pick crash because I do not think we want to specify exactly how the process ends, except that it will probably look like it didn't exit successfully. trap and fault seem to me like there should be a handler that I can install to run when this intrinsic is invoked.

Rollup merge of rust-lang#163621 - tgross35:const-abort-immediate, r=…

Unrolled build for #163621 in rollup 163630

Rollup merge of rust-lang#163574 - tgross35:intrinsics-abort-rename, …

Unrolled build for #163574 in rollup 163680

Rollup merge of #163574 - tgross35:intrinsics-abort-rename, r=clarfon…

Rollup merge of #163621 - tgross35:const-abort-immediate, r=RalfJung,…

Rollup merge of #163574 - tgross35:intrinsics-abort-rename, r=clarfon…

Rollup merge of #163621 - tgross35:const-abort-immediate, r=RalfJung,…

Navigation Menu

Repository navigation

Tracking Issue for abort_immediate (abort in core) #154601

Public API

Steps / History

Unresolved Questions

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for abort_immediate (abort in core) #154601

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

saethlin commented on Mar 31, 2026

CAD97 commented on Mar 31, 2026

ChrisDenton commented on Mar 31, 2026

ds84182 commented on Mar 31, 2026

nia-e commented on Aug 8, 2026

ChrisDenton commented on Aug 8, 2026

10 remaining items

tgross35 commented on Oct 1, 2026

tgross35 commented on Oct 1, 2026

eaglgenes101 commented on Oct 1, 2026

saethlin commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions