Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic)

[Centril]

This is a tracking issue for the RFC "Allow panicking in constants" (rust-lang/rfcs#2345).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

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

Blockers:

• ICE: const_panic: ICE on non-&str panic payload #66693

[clarfonthey]

Don't forget expect and all the other unwrap-like methods. :P

[vi]

I suppose unimplemented!() and unreachable!() should also be included?

[SimonSapin]

I think they would be "automatically", since macros don’t have a separation similar to fn v.s. const fn.

[oli-obk]

I'll add some tests to #52011, but yes, it just works.

[Centril]

Triage: @oli-obk so this is implemented now, right?

[oli-obk]

Yes

[IsaacWoods]

Now this is implemented, is there anything stopping Option::unwrap and friends from becoming const fns (I'm assuming with a rustc_const_unstable(feature = "??"))?

[Centril]

@IsaacWoods to my knowledge there shouldn't be anything in the way of that.

[IsaacWoods]

@Centril great! I'll start work on a PR in that case

[clarfonthey]

The thing in the way of that is running fmt::Debug::fmt in const context.

…oh, right, I was thinking in terms of Result::unwrap and Result::expect. Option should be fine.

[IsaacWoods]

On second thoughts, even Option is still blocked I think - I don't think we can use match in const contexts yet either

[oli-obk]

Yea, we need conditions in constants first

[Centril]

Right; bummer.

@oli-obk Any thoughts about the first unresolved question?

[oli-obk]

I'm for basically reporting it verbatim, but having the same prefix (error[0080]:) as all other errors.

[Centril]

@oli-obk I like that; (and it's a diagnostics issue anyways, not part of the spec, so it is up to T-compiler to decide this...).

[jhpratt]

Now that #86998 is merged, this should be good to stabilize, correct?

[oli-obk]

I'm still unhappy that in 2018 we can do panic!(some_computed_str) but in 2021 we can't do the equivalent, but it seems better to only allow literal strings for now than to not allow any custom panicking. Imo this is purely a T-libs issue, but I'll let @rust-lang/wg-const-eval weigh in on that before escalating to T-libs for stabilization.

[RalfJung]

it seems better to only allow literal strings for now than to not allow any custom panicking

👍 as long as this is enforced properly(i.e. everything accepted in 2018 on stable also works in 2021).

[oli-obk]

it is not yet. Not sure how doable that is, it may be easier to just figure out how to do panic!("{}", some_computed_str) on all editions.

[abonander]

For our planned usage of this feature in SQLx we would really prefer either support for formatting or being able to compute panic strings. We can sorta work around it if the panic strings need to be literals but it won't be the greatest.

[clarfonthey]

One thing that I noticed which kind of sucks: this being unstable means that you can't use todo!() in consts. Although I understand not wanting to stabilise that so that people don't use it instead of panic.

[rodrimati1992]

I've noticed that you can use a non-static foo: &str as an argument to panic!("{}", foo), is it intentional that it doesn't require a 'static one?
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8bd048da90965a526dbc98d187f56c56

const _: () = {
    let arr = [b'b', b'y', b'e'];
    let msg: &str = unsafe{ std::str::from_utf8_unchecked(&arr) };

    panic!("{}", msg)
};

if it is intentional, I have an idea for how to implement const panics with bounded-length formatted arguments in a library.

[oli-obk]

Yes this is intentional. Getting that to work was actually a blocker for stabilization.

[tmandry]

Is there an issue tracking support for non-&str panic arguments in consts?

Right now the compiler just gives an error (implemented in #80734) "argument to panic!() in a const context must have type &str", but there's no error code or other explanation text.

The RFC doesn't mention this limitation.

[oli-obk]

There's no special tracking for it. It's essentially just blocked on the fact that you can't implement Display or Debug in a way that is callable in a const context.

[rodrigocfd]

Damn, I just stumbled upon a situation where a I need a fallible enum construction, like this one:

const fn parse_bool(s: &str) -> bool {
    match s {
        "true" => true,
        "false" => false,
        other => panic!("`{}` is not a valid bool", other), // CAN'T DO THAT!
    }
}

Time to refactor a huge workaround 😞

I really hope this issue can be fixed, I have so many other situations where it would make my design correct.

[golddranks]

@rodrigocfd You can already panic in const fns, you just can't use string formatting machinery yet. Remove the {} and , other and the panic part compiles. However, &str matching doesn't seem to work in const fns yet, as that requires const-agnostic traits.

Also a side note, panicing is a bit suspect strategy if you are expecting the matching to fail with some inputs.

This is a closed tracking issue for panics in const and not meant for general discussion, if you need help within the current capabilities of the compiler, try https://users.rust-lang.org or https://www.reddit.com/r/rust/

[rodrigocfd]

@golddranks thank you.