Stabilize RFC 2345: Allow panicking in constants

[nikomatsakis]

Stabilization report

🛑 Issue with Rust 2021 🛑

Stabilization is currently blocked on resolving how this works with Rust 2021

Summary

This feature allows panicking within constants and reporting a custom message as a compile-time error.

The following code will become valid on stable:

const fn foo(val: u8) {
    assert!(val == 1, "val is not 1");
}

const MSG: &str = "custom message";

const _: () = std::panic!(MSG);
const _: () = panic!("custom message");

The message looks like:

error: any use of this value will cause an error
 --> src/main.rs:4:15
  |
4 | const _: () = std::panic!(MSG);
  | --------------^^^^^^^^^^^^^^^^-
  |               |
  |               the evaluated program panicked at 'custom message', src/main.rs:4:15
  |
  = note: `#[deny(const_err)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Motivation for this RFC can be found here: https://rust-lang.github.io/rfcs/2345-const-panic.html#motivation

More examples can be found here: https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/consts/const-eval/const_panic.rs

Edge cases & tests

• https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/consts/const-eval/panic-never-type.rs
• https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/consts/const-eval/panic-assoc-never-type.rs
• https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/consts/issue-66693.rs
• https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/consts/control-flow/short-circuit-let.rs

Some questions which should be resolved in the future

We have some "unresolved questions" but they aren't an actual blocker.

• Should there be some additional message in the error about this being a panic turned error?
  Or do we just produce the exact message the panic would produce?
• This change becomes really useful if Result::unwrap and Option::unwrap become const fn, doing both in one go might be a good idea.

See the brief summary comment here: #51999 (comment)

Originally posted by @JohnTitor in #51999 (comment)

[Aaron1011]

One additional unresolved question that @RalfJung had brought up previously - do we ever want to allow catching panics in constants? The only issue I can think of would be users expecting panic!() to always abort compilation - but users should be aware that panics can be caught, especially if they're writing a const fn, which can also be called at runtime.

[nikomatsakis]

Is the question really about whether we want to allow catching panics in constants?

[Aaron1011]

IIRC, the original question was about whether panic!() is compatible with later deciding we want to allow catching panics in constants.

[Nemo157]

const MSG: &str = "custom message";
const _: () = std::panic!(MSG);

This specific example triggers the non_fmt_panic lint, and will not compile in Edition 2021. To support usecases like this we would need to make std::panic::panic_any a const fn too (or get support for traits-in-const to allow using the format machinery).

[nikomatsakis]

@Aaron1011 so in other words, the question is, will someone write a constant that panics and assumes that this panic aborts compilation in some crucial way, but then we introduce a wrapper that captures the panic, and now the safety guarantee is not upheld?

[jhpratt]

Personally I'd like to be able to panic in a const context to perform data validation from a macro. This would allow me to eliminate a procedural macro. If a const panic could be caught, that would effectively eliminate the ability to validate data (I think, feel free to correct me).

Reference to what I hope will be possible once const_panic is stabilized: time-rs/time#322

[rodrimati1992]

@jhpratt The code in that issue would not be affected by catch_unwind being usable in const contexts, since it stores the validated data in a const before returning it.

[CodesInChaos]

@Nemo157 In my comment on the original issue I proposed other options, which might be easier to implement:

1. make formatting work for string slice arguments, without relying on formatting traits
2. make the precise pattern panic!("{}", str) work, where str is a string slice
3. make panic_any const, but only if the argument is a string slice.

[nikomatsakis]

I'd like an example where there is a panic that should abort compilation but catching it would produce a problem -- it feels like the panic erases the const value being produced, so I'm not clear on what kind of error would be swallowed that would be a problem.

[RalfJung]

@Aaron1011 wrote

One additional unresolved question that @RalfJung had brought up previously - do we ever want to allow panicking in constants?

I am confused -- yes we do want to allow panicking in constants...?

EDIT: Oh, I guess you forgot a "catch" somewhere... could you edit the text? Looks like I am not the only one who got confused. ;)

[RalfJung]

it feels like the panic erases the const value being produced, so I'm not clear on what kind of error would be swallowed that would be a problem.

I guess if a const fn would perform some validation and then return (), if you can catch panics you can circumvent this validation.

But I don't see how this would be any more problematic at compile-time than it is at run-time.

[RalfJung]

Another question that came up is if we should change the error that is emitted when a const/static panic such that it can not be allowed. I am sympathetic to that idea. The only reason CTFE error can be allowed at all is backwards compatibility, and there is no such concern with panics.

[nikomatsakis]

I see. I definitely think it should be a hard error.