Change:
The panic payload of the macro (as passed on to ) is generic, but the CTFE panic support assumes it will always be an . This leads to ICEs: Cc
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?
Alternatively constck could require the argument to have type .
also requires a
Yeah, the libcore panic machinery does not support non-format-string panics.
Aye, left out the latter of my message. is likely the most common argument to , and it's not unusual with e.g. ; so I agree that waiting for const traits before supporting any other arguments is reasonable.
Im hitting this ICE on stable without feature flag:
Hm indeed, that is interesting: 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?
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.
:rofl: So what would be a possible approach here? Replace such consts by early enough that their MIR never actually gets evaluated? We might as well use this issue, IMO...
That would require us to mutate all MIR and potentially even HIR. Other possible solutions: poison the mir Body if const checks fail (by adding a field like or by just nuking the body by replacing it with ) and thus make allow const evaluation to check if the mir Body failed the checks and bail out before doing anything make the have an field similar to
On second thought, let's leave this issue for the ICE, and make a new one for "we can trigger nightly-only const code on stable because we don't abort compilation early enough":
Given that this ICE is pre-existing, as shown by , can we un-block ? I'd really like to see const_panic stabilized, and this seems like a minor issue to be blocking on.
That comment is an example of accidentally partially exposing an unstable feature on stable -- a separate bug tracked in I don't see how that's an argument for shipping that feature on stable when it is broken. In particular, applies to all unstable const features. Fixing this bug here is not even that hard I think: somewhere around here there needs to be a check that the argument has type . Re: , AFAIK that one is also blocked on figuring out how the diagnostics should look like, and a further concern (though maybe not blocking) is .
I guess that might make this a non-issue, where it is proposed also would require as first argument.
For reference: , which was recently merged. The plan is to fix the behaviour of in the Rust 2021 edition. Given that this ICE is listed as a blocker for , does this mean that stabilizing that will have to wait for the next edition?
No, because breaking changes are allowed to be made to unstable features without moving to a new edition; that's kinda the whole idea. The 2021 edition will effectively just extend the same restriction to all invocations, const context or not.
I'd like to tackle this but I'm not very experienced with the CTFE code. I get that we need to check from the that we've matched on in this branch and we need to match on the enum, but: For the first question, I see and that we probably want to check that the type of the tuple and that there's variants of that are , but do we stop the iteration when we get one that is a type? Is the projection list always guaranteed to terminate in a variant of that has a ? And once we have an instance of , do we just check that there's any_ projection in the list that has a ?
you can use to get the type of the . Then you can test its to be .

Discussion:
} } <ins> /// A call to a `panic()` lang item where the first argument is _not_ a `&str`. #[derive(Debug)] pub struct PanicNonStr; impl NonConstOp for PanicNonStr { fn build_error(&self, ccx: &ConstCx<'_, 'tcx>, span: Span) -> DiagnosticBuilder<'tcx> { ccx.tcx.sess.struct_span_err( span, "argument to `panic!()` in a const context must have type `&str`", ) } } </ins> #[derive(Debug)] pub struct RawPtrComparison; impl NonConstOp for RawPtrComparison {

self.super_terminator(terminator, location); match &terminator.kind { <del> TerminatorKind::Call { func, .. } => { </del> <ins> TerminatorKind::Call { func, args, .. } => { </ins> let ConstCx { tcx, body, param_env, .. } = *self.ccx; let caller = self.def_id().to_def_id();

} // At this point, we are calling a function, `callee`, whose `DefId` is known... if is_lang_panic_fn(tcx, callee) { self.check_op(ops::Panic); <ins> // const-eval of the `begin_panic` fn assumes the argument is `&str` if Some(callee) == tcx.lang_items().begin_panic_fn() { match args[0].ty(&self.ccx.body.local_decls, tcx).kind() { ty::Ref(_, ty, _) if ty.is_str() => (), _ => self.check_op(ops::PanicNonStr), } } </ins> return; }

<ins> // This is a separate test from `issue-66693.rs` because array lengths are evaluated // in a separate stage before `const`s and `statics` and so the error below is hit and // the compiler exits before generating errors for the others. #![feature(const_panic)] fn main() { let _ = [0i32; panic!(2f32)]; //~^ ERROR: argument to `panic!()` in a const context must have type `&str` // ensure that conforming panics are handled correctly let _ = [false; panic!()]; //~^ ERROR: evaluation of constant value failed // typechecking halts before getting to this one let _ = ['a', panic!("panic in array len")]; } </ins>

<ins> error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-66693-panic-in-array-len.rs:8:20 | LL |     let _ = [0i32; panic!(2f32)]; |                    ^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0080]: evaluation of constant value failed --> $DIR/issue-66693-panic-in-array-len.rs:12:21 | LL |     let _ = [false; panic!()]; |                     ^^^^^^^^ the evaluated program panicked at 'explicit panic', $DIR/issue-66693-panic-in-array-len.rs:12:21 | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0080`. </ins>

<ins> // Tests that the compiler does not ICE when const-evaluating a `panic!()` invocation with a // non-`&str` argument. #![feature(const_panic)] const _: () = panic!(1); //~^ ERROR: argument to `panic!()` in a const context must have type `&str` static _FOO: () = panic!(true); //~^ ERROR: argument to `panic!()` in a const context must have type `&str` const fn _foo() { panic!(&1); //~ ERROR: argument to `panic!()` in a const context must have type `&str` } // ensure that conforming panics don't cause an error const _: () = panic!(); static _BAR: () = panic!("panic in static"); const fn _bar() { panic!("panic in const fn"); } fn main() {} </ins>

<ins> error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-66693.rs:13:5 | LL |     panic!(&1); |     ^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-66693.rs:6:15 | LL | const _: () = panic!(1); |               ^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-66693.rs:9:19 | LL | static _FOO: () = panic!(true); |                   ^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors </ins>

<del> struct Bug([u8; panic!(1)]); //~ ERROR panicking in constants is unstable </del> <ins> // Note: non-`&str` panic arguments gained a separate error in PR #80734 // which is why this doesn't match the issue struct Bug([u8; panic!("panic")]); //~ ERROR panicking in constants is unstable </ins> fn main() {}

error[E0658]: panicking in constants is unstable <del> --> $DIR/issue-76064.rs:1:17 </del> <ins> --> $DIR/issue-76064.rs:3:17 </ins> | <del> LL | struct Bug([u8; panic!(1)]); |                 ^^^^^^^^^ </del> <ins> LL | struct Bug([u8; panic!("panic")]); |                 ^^^^^^^^^^^^^^^ </ins> | = note: see issue #51999 <https://github.com/rust-lang/rust/issues/51999> for more information = help: add `#![feature(const_panic)]` to the crate attributes to enable