const_panic: ICE on non-&str panic payload

[RalfJung]

The panic payload of the std::panic! macro (as passed on to begin_panic) is generic, but the CTFE panic support assumes it will always be an &str. This leads to ICEs:

#![feature(const_panic)]

const C: () = {
    panic!(1234);
};

Cc @oli-obk

[oli-obk]

I guess we could support this, but we'd have to find some way to render the errors. Maybe we need to wait for const traits so we can require const Debug?

[RalfJung]

Alternatively constck could require the argument to have type &str.

[memoryruins]

core::panic! also requires a &str

#![feature(const_panic)]
const _: () = core::panic!(1234);

error[E0308]: mismatched types
 --> src/lib.rs:2:28
  |
2 | const _: () = core::panic!(1234);
  |                            ^^^^ expected `&str`, found integer

[RalfJung]

Yeah, the libcore panic machinery does not support non-format-string panics.

[memoryruins]

Aye, left out the latter of my message. &str is likely the most common argument to panic!, and it's not unusual with e.g. core::panic!; so I agree that waiting for const traits before supporting any other arguments is reasonable.

[DutchGhost]

Im hitting this ICE on stable without feature flag:

struct Bug([u8; panic!(1)]);

[RalfJung]

Hm indeed, that is interesting:

error[E0658]: panicking in constants is unstable
 --> src/lib.rs:1:17
  |
1 | struct Bug([u8; panic!(1)]);
  |                 ^^^^^^^^^
  |
  = note: see issue #51999 <https://github.com/rust-lang/rust/issues/51999> for more information
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

thread 'rustc' panicked at '`ref_to_mplace` called on non-ptr type', src/librustc_mir/interpret/place.rs:292:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

@rust-lang/wg-const-eval any idea why we go on here after seeing an error? Does this kind of behavior mean any part of CTFE is reachable on stable somehow?

[oli-obk]

Does this kind of behavior mean any part of CTFE is reachable on stable somehow?

yes. We're not gating CTFE on whether there were stability (or any other static checks) failing. I've been abusing this since 1.0 to demo things on the stable compiler and never got around to fixing it. I don't even know if we have a tracking issue for it.