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

[jhpratt]

r=me with completed FCP

View changes since this review

[scottmcm]

Lang hat: zero concerns here. The extremely similar let _g = OnDrop::new(|| panic!()); panic!() is already on the "obviously should be const" list for me, so giving a more direct way to do something fatal isn't a concern. Or I guess const extern "C" fn foo() { panic!() } already compiles and calling it aborts because the panic isn't allowed to unwind across the function boundary.

@rfcbot reviewed

---

Personally: I like crash, actually. Gives a nice distinction from exit in why you might want to use one or the other if both are available to you, in a way that "abort immediately" doesn't do as well to me.

[CAD97]

The original implementation used abort_immediate simply to get a version available, taking the name from panic=immediate-abort. I concur that crash is a good name for the function.

[the8472]

We should at least look at which flavors of aborting/crashing we have/may have in the future. And if the names distinguish them well enough

• crash
• abort
• panic
• panic_nounwind
• (internally) rtabort (print + abort)
• exit
• ???

[clarfonthey]

As discussed in the meeting: basically, we'd like to ensure a few things before stabilisation, namely:

• As @the8472 mentioned, how this fits in with all the various "process EOL" methods.
• We should probably recommend panicking (potentially in a non-unwinding way) over aborting, since in general you want error messages.

Otherwise, people seemed pretty amenable to the new name.

[tmandry]

No concerns from me on the name or the new intrinsic.

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[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-x86_64-gnu-gcc-core-tests failed! Check out the build log: (web) (plain enhanced) (plain)

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

Important

For more information how to resolve CI failures of this job, visit this link.