[tgross35]

View all comments

Stabilize the following, including const:

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

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

The rename is happening in #164730 (this is stacked on top).

There are three considerations for libs, which are the unresolved questions on the tracking issue:

1. Do we still want this even if we can eventually add core::process::abort() which calls to libc::abort() on platforms with an OS? I think yes: having effectively a single-instruction way to terminate is useful for performance reasons and as a fallback, e.g. running on an OS but without linking a libc.
2. What name do we want? Reception to abort_immediate seems lukewarm based on tracking issue discussion. I'm proposing we go with crash crash because it appears to be one of the more unobjectionable options there.
3. Should this live in core::process or somewhere else? There isn't really a process without an OS. But for consistency with abort, I think it is fine.

Lang is involved because this is stabilizing a new const intrinsic that can't really be replicated with existing stable features, though panic!() is close.

Closes: #154601 (tracking issue)

[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

⚠️ #[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
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: compiler
• compiler expanded to 77 candidates
• Random selection from 20 candidates

[RalfJung]

In terms of naming, abort_immediate seems ungrammatical to me -- it should be abort_immediately, no?

crash also seems fine for me. I associate "crash" with something unsafe so the docs should emphasize that this is a safe form of crashing, but that doesn't have to appear in the name.

(Also why are there two PRs? It's confusing.^^ Is this the right one for discussion?)

[tgross35]

For libs there are a couple questions, mostly name. Personally I'm most okay with crash or abort_ungraceful/abort_ungracefully. I could live with abort_immediate/abort_immediately but understand the hesitation, since abort itself is reasonably "immediate".

I am going to propose FCP here but expect there will be naming discussion at the meeting. So I suppose only check your box if you're okay with any name, otherwise hold off until Tuesday.

For lang, this is a new const intrinsic that does something slightly novel. It's right on the line of what's been delegated so I think having your FCP doesn't hurt, but it is effectively a less nice panic!().

@rfcbot merge libs,lang
@rustbot label +I-libs-nominated,+I-lang-nominated
Cc feature author @CAD97

[rust-rfcbot]

@tgross35 has proposed to merge this. The next step is review by the rest of the tagged team members:

• @ChrisDenton
• @Mark-Simulacrum
• @cuviper
• @dtolnay
• @joshtriplett
• @nia-e
• @nikomatsakis
• @scottmcm
• @the8472
• @thomcc
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[jhpratt]

I actually really like the name "crash". It's short and descriptive, particularly as opposed to "abort".

[tgross35]

In terms of naming, abort_immediate seems ungrammatical to me -- it should be abort_immediately, no?

crash also seems fine for me. I associate "crash" with something unsafe so the docs should emphasize that this is a safe form of crashing, but that doesn't have to appear in the name.

Agreed that abort_immediately would be more correct, or immediate_abort. I actually originally preferred abort_ungracefully for a bit more clarity with the same adverb reason, but crash is much less clunky.

I think I'm going to prepare another docs update PR that can include that clarification, but am going to hold off until a name is decided.

(Also why are there two PRs? It's confusing.^^ Is this the right one for discussion?)

It's always nice for the stabilization PR to be just stabilization so there's a little more buffer time after any other changes. Plus stabilization needs to wait on FCP while other changes don't.

But yeah, this PR serves as a central place to discuss both.

[theemathas]

I like the name crash because I think it will make the user the least surprised by whatever the function ends up doing, since users are unlikely to have expectations that a "crash" must happen in a certain way.

Naming it with any variation of abort would probably lead to someone eventually filing an issue complaining that it produces SIGILL or something else instead of SIGABRT.

[tgross35]

r? libs

[Jules-Bertholet]

I think abort_immediate/abort_immediately is good. It makes it clear how this operation differs from other ways of ungracefully exiting the process, e.g. a non-unwinding panic. Personally, I would expect crash to be "abort the process abnormally in the most debuggable way", not necessarily the fastest way.

[traviscross]

Thanks for thinking of lang. Agreed this is nominally a new intrinsic. From a lang side:

@rfcbot reviewed

As input to the libs decision on the name, I think that crash is a great name for this. Short, evocative, visceral. It's not fussy, like abort_something_something. Everything a good name should be. +1 to @tgross35's choice on this.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job test-aarch64-gnu-llvm-22-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[COPY] sysroot_tests source
[PATCH] "sysroot_tests" <- "0027-sysroot_tests-128bit-atomic-operations.patch"
error: patch failed: coretests/tests/lib.rs:2
error: coretests/tests/lib.rs: patch does not apply
Patch failed at 0001 Disable 128bit atomic operations
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
cd "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-codegen/cg_clif/build/sysroot_tests" && "git" "-c" "user.name=Dummy" "-c" "[email protected]" "-c" "core.autocrlf=false" "-c" "commit.gpgSign=false" "am" "/checkout/compiler/rustc_codegen_cranelift/patches/0027-sysroot_tests-128bit-atomic-operations.patch" "-q" exited with status ExitStatus(unix_wait_status(32768, "exit status: 128"))
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo run --target aarch64-unknown-linux-gnu -Zbinary-dep-depinfo -j 4 -Zroot-dir=/checkout -Zembed-metadata=no --locked --color=always --profile=release --manifest-path /checkout/compiler/rustc_codegen_cranelift/build_system/Cargo.toml -- test --download-dir /checkout/obj/build/cg_clif_download --out-dir /checkout/obj/build/aarch64-unknown-linux-gnu/stage2-codegen/cg_clif --no-unstable-features --use-backend cranelift --sysroot llvm --skip-test testsuite.extended_sysroot [workdir=/checkout/compiler/rustc_codegen_cranelift]` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/test.rs:4510:25
Executed at: src/bootstrap/src/core/build_steps/test.rs:4554:26

Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::CodegenCranelift { compilers: RustcPrivateCompilers { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target_compiler: Compiler { stage: 2, host: aarch64-unknown-linux-gnu, forced_compiler: false } }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4496
Build completed unsuccessfully in 0:20:30
  local time: Sat Oct 31 01:55:14 UTC 2026

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[jhpratt]

@bors r+

[rust-bors]

❌ Cannot approve commit bfcdcbc, because CI currently fails on this PR. Use @bors r+ force to override the PR CI check.