Stabilize RFC 2345: Allow panicking in constants

[oli-obk]

Stabilization report

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");
}

// can be also computed by manually creating a `&[u8]` and
// from_utf8_unchecked.
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)

Previous attempt: #85194 (This was blocked because it was not possible to use a generated panic message, only literal strings were allowed, which has been resolved in #88954)

Originally posted by @JohnTitor in #51999 (comment)

cc @rust-lang/wg-const-eval

[kpreid]

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?

My perspective as someone who is frequently trying to make good error messages:

1. Yes, there should be some indication that the message text originated from user code — otherwise you'll get confused users asking “what does this compiler error mean” when using a library's const fns.
2. On the other hand, it is very helpful to readability if the message is presented as a message in itself rather than a quoted fragment with both leading and trailing text inside a larger error message. Quotation with content escapes, and line wrapping, also harm scannability, and make it less likely that a user will understand that this is the relevant information. (Rust's run-time panics unfortunately already have this problem.)

For example, the existing example

4 | const _: () = std::panic!("{}", MSG);
  | --------------^^^^^^^^^^^^^^^^^^^^^^-
  |               |
  |               the evaluated program panicked at 'custom message', src/main.rs:4:15

would in my opinion be better formatted as

4 | const _: () = std::panic!("{}", MSG);
  | --------------^^^^^^^^^^^^^^^^^^^^^^-
  |               |
  |               the evaluated program panicked at src/main.rs:4:15 with:
  |                   custom message

The first sample has the virtue of more closely matching runtime behavior; but I think there should be generally higher expectations for readability from messages during compilation than those which must be formatted by handler code embedded in the final binary.

[rodrimati1992]

would in my opinion be better formatted as

4 | const _: () = std::panic!("{}", MSG);
  | --------------^^^^^^^^^^^^^^^^^^^^^^-
  |               |
  |               the evaluated program panicked at src/main.rs:4:15 with:
  |                   custom message

I agree. I'd also expect multiline panic messages to stay indented, so that they can be easily distinguished from the following compilation errors.

I would prefer if both const panics and compile_error were consistent in that, and change this:

error: 
hello
world

 --> src/main.rs:1:1
  |
1 | / compile_error!{"
2 | | hello
3 | | world
4 | | "}
  | |__^

error: could not compile `playground` due to previous error

to the indented style you're proposing.

[RalfJung]

There was some long discussion about error formatting in a previous PR as well, more than a year ago... maybe someone can dig up the link.

I think const panic messages should be consistent with other kinds of errors that stop const-evaluation. So, I am not a fan of special-casing const panic error formatting. But I am open to improving const-eval error rendering in general.

[joshtriplett]

Seems reasonable; let's get consensus:

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

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!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

Important to note: This will make assert!(1 == 2, "...") work in const, but assert_eq!(1, 2, "...") will still not work, since it uses more complicated formatting.

[c410-f3r]

It is not the scope of this issue but I would like to chime to draw the attention of also considering "constifying" Result::unwrap() and Option::unwrap(). Without them, people will probably write

const FOO: () = {
    let _ = match SOME_OPERATION {
        Err(_err) => panic!("SOME ERROR"),
        Ok(elem) => elem
    };
};

instead of the much simpler

const FOO: () = {
    let _ = SOME_OPERATION.unwrap();
};

[RalfJung]

Result::unwrap is way out of reach for now since it formats the Err value.

But Option::unwrap and Option::expect would be reasonable to stabilize I think -- they are basically forms of assert.

[nikomatsakis]

@rfcbot reviewed