Skip to content

Conversation

Amanieu
Copy link
Member

@Amanieu Amanieu commented Apr 1, 2025

This is similar to panic_immediate_abort except that all panics are considered immediate UB and can therefore be optimized away as unreachable by the compiler.

This has been tested on regalloc3 where it resulted in a 10% speedup compared to using a normal standard library, mainly due to the elimination of bounds checks.

While it may seem that this feature merely to satisfy those with a reckless thirst for performance at any cost, it is also useful for saner heads as a profiling tool to investigate the impact of unnecessary safety check and find places where unsafe code could be used to avoid them.

This is similar to `panic_immediate_abort` except that all panics are
considered immediate UB and can therefore be optimized away as
unreachable by the compiler.

This has been tested on
[regalloc3](https://github.com/Amanieu/regalloc3) where it resulted in a
10% speedup compared to using a normal standard library, mainly due to
the elimination of bounds checks.

While it may seem that this feature merely to satisfy those with a
reckless thirst for performance at any cost, it is also useful for saner
heads as a profiling tool to investigate the impact of unnecessary
safety check and find places where unsafe code could be used to avoid
them.
@rustbot
Copy link
Collaborator

rustbot commented Apr 1, 2025

r? @jhpratt

rustbot has assigned @jhpratt.
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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 1, 2025
#[rustc_const_stable_indirect] // must follow stable const rules since it is exposed to stable
pub const fn panic_fmt(fmt: fmt::Arguments<'_>) -> ! {
if cfg!(feature = "panic_unreachable_unchecked") {
// SAFETY: it's not...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This safety comment is inadequate, the condition of soundness relies on the programmer asserting panics will never happen, so a more accurate comment is:

Suggested change
// SAFETY: it's not...
// SAFETY: The user of this flag asserts that a panic will never happen in their codebase
if you want to do april fools, go all in :^)

@jhpratt
Copy link
Member

jhpratt commented Apr 1, 2025

r=me with or without the comment at your discretion. I personally find it sufficiently obvious that such an option is inherently unsound if reached.

@scottmcm scottmcm added the april-1st Started on the 1st of April label Apr 1, 2025
# Make panics and failed asserts immediately abort without formatting any message
panic_immediate_abort = ["core/panic_immediate_abort"]
# Make the optimizer assume panics are unreachable.
panic_unreachable_unchecked = [
Copy link
Contributor

@MikailBag MikailBag Apr 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose to rename this feature to unsafe_panic_unreachable_unchecked, so that its name includes word unsafe, because this is actually an unsafe API (like #[no_mangle] attribute), and AFAIU all unsafe APIs tend to include unsafe in their usage (as part of their name, as a surrounding unsafe block, etc).

Alternatively, if this PR is a joke, I'd consider crabs_never_panic as an alternative name.

Copy link

@Fyko Fyko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@Amanieu
Copy link
Member Author

Amanieu commented Apr 1, 2025

It turns out that @saethlin has a much better implementation of this that doesn't even require -Z build-std! Since that approach is clearly better (and absolutely unrelated to the fact that today's date is now April 2nd) I will close this PR.

@Amanieu Amanieu closed this Apr 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

april-1st Started on the 1st of April S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants