Tracking Issue for panic::always_abort()

[ijackson]

Feature gate: #![feature(panic_always_abort)]

This is a tracking issue for std::panic::always_abort().

This function causes all future panics to abort. It is useful in the child after libc::fork, and Command uses it for that.

Public API

// std::panic

pub fn always_abort();

Steps / History

• Implementation: Do not allocate or unwind after fork #81858
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[Kixunil]

This would be pretty useful to not have to implement abort bomb every time one wants to handle aborting nicely. That means when a piece of code knows for a fact it has to abort (not panic!) due to safety issues but wants to print/log a message and avoid printing code panicking causing it to skip abort. However from the discussion in the impl PR it seems this sets global flag instead of thread-local one, which is undesirable.

If it was guaranteed to be thread-local it'd increase usefulness of this considerably.

[RalfJung]

I filed this as a separate issue: #122940.

[peter-lyons-kehl]

Summary of this comment: Let's make this API more future-proof

The current/initial use case & implementation of always_abort() is legitimate & useful, but rare. Many other and more mainstream use cases hope for other ways to restrict panicking/hooks/unwinding. (Those other use cases don't shout, because their individual pain hasn't reached the threshold, or they don't have capacity/ability to see/ask about what could be done; but they do exist.)

I'm not saying that there will be such other ways at runtime - instead, it may be by other Cargo.toml -> [profile.xyz] -> panic = ... strategies, or by some other build time/link time configuration. For now, let's assume that there may be other similar functions later.

As a minimum, suggest choosing a function name convention, so that more similar functions can be added later, and they

• share a common prefix, so that they are listed together in rustdoc output, and they auto-complete easier in IDE's (API discoverability),
• indicate whether the function applies globally (to all threads), or locally (to the current thread), or to a "subtree"/scope or a list of threads (for example, std::thread::Scope). (Again, I'm not saying that there will be such functions, and they may be cost-prohibitive.)
• some may be no_std-compatible and available in core (or no_std & alloc-compatible and available in alloc) and re-exported in std
• can disable/revert a choice of behavior indicated/activated earlier by a related function
• can query the current state/mode; libraries may want to know this. Because of this let's not use a verb as a common prefix (or example, behave_ would make a query function name difficult: behave_enabled()), but use a noun (behavior_ -> a query function: behavior_enabled() or behavior_active()).

The following examples use behavior_ prefix. The only one shorter that I can think of is flow_, but that may be confusing/less obvious. Anything better?

// Non-reversible
behavior_global_always_abort()

// "xyz", "abc", "pqr" represent a name for the behavior:

// Reversible, using _undo postfix
behavior_global_xyz()
behavior_global_xyz_undo()

// Non-reversible, local thread only
behavior_thread_abc()

// Reversible, local thread, using _on() and _off() postfix - probably not a good choice of postfixes, here only as an example
behavior_thread_pqr_on()
behavior_thread_pqr_off()

// Non-reversible, a scope of threads. If used with std::thread::scope(), the reference here can't be mutable, so this needs some interior mutability; it could probably be called only before creating any scoped threads. Most likely too expensive to have a way to reverse.
behavior_scoped_xyz(&'std::thread::Scope)

Again, I'm not saying that there will ever be ..._on() and ..._off(), or ..._xyz() and ..._xyz_undo() or similar pairs - we may choose to accept a closure and to undo/revert the behavior at the end of the closure (in an internal guard object's drop()). But, if we can't say now whether we'd ever allow (or not allow) such ..._on() and ..._off() function pairs, let's choose name conventions that would play well together.

Also, if we rename this function, suggest changing the #![feature(panic_always_abort)] name respectively. Any existing users (on nightly) will have to rename the function anyway, so they may just as well rename the #![feature(...)]. This way there won't be obsolete feature name in the source confusing people from then on.

Side note: There are only two consumers of the current feature & function (other than rust-lang/rust itself and its clones) that are "popular" on GitHub (tracked by Sourcegraph Search): https://github.com/Artisan-Lab/RULF/blob/develop/src/test/ui/process/process-panic-after-fork.rs and https://github.com/dlrobertson/capsicum-rs/blob/main/capsicum/tests/lib.rs.

Side question: While I don't think we have to notify nightly users about any renames, I'm curious if there is any efficient way to get src/lib.rs, src/main.rs and src/bin/* of all current crates on crates.io (so as to detect #![feature(..., panic_always_abort...)]. I believe https://play.predr.ag/rustdoc and https://crates.meilisearch.com get a limited subset, and I don't see a way to get this out of them efficiently. https://github.com/dtolnay/get-all-crates gives all .crate files - but is there a way to get just the selected files out of crates.io (or some other place)?