[tgross35]

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