Const-eval errors in dead functions are optimization-dependent

[CAD97]

I tried this code: [playground]

#![feature(inline_const)]

pub fn cause_late_error<T>() {
    const {
        panic!()
    };
}

fn main() {
    let a = 1;
    let b = 2;
    if a + b == 5 {
        cause_late_error::<()>();
    }
}

I expected to see this happen:

error[E0080]: evaluation of `cause_late_error::<()>::{constant#0}` failed
 --> src/main.rs:7:9
  |
7 |         panic!()
  |         ^^^^^^^^ the evaluated program panicked at 'explicit panic', src/main.rs:7:9
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

note: the above error was encountered while instantiating `fn cause_late_error::<()>`
  --> src/main.rs:13:9
   |
13 |         cause_late_error::<()>();
   |         ^^^^^^^^^^^^^^^^^^^^^^^^

Instead, this happened: it compiled without any warnings.

Meta

Playground nightly, 1.69.0-nightly (2023-01-30 001a77f)

Related

• dead-code optimize if const { expr } even in opt-level=0 #85836
• Stabilise inline_const #104087
• unused function is not monomorphized, so post-mono lints do not show up (in particular affects associated and inline consts) #106617

Potential fix:

• recursively evaluate the constants in everything that is 'mentioned' #122568

[CAD97]

@rustbot modify labels +T-lang

[joshtriplett]

let _: c_void = screaming.into();

Ahem. Thank you for this most illuminating and horrifying example.

[oskgo]

On a related note, there's also this following code that compiles in release mode but fails to compile in debug mode: [playground]

#![feature(inline_const)]

#[inline(always)]
fn falser() -> bool {
    false
}

fn has_late_error<T>() {
    const {
        panic!()
    };
}

fn main() {
    if falser() {
        has_late_error::<()>();
    }
}

Maybe it makes more sense to track inline_const's interactions with optimizations as a whole?

[RalfJung]

To be clear, this has nothing to do with inline_const, right? Associated consts show the same behavior?

[CAD97]

I believe so, yes; any post-mono error should work. It's just significantly easier to show with panicking inline const than any other post-mono error, and much more accessible.

I believe this just results from cause_late_error::<()> being determined dead by MIR analysis and thus not monomorphized. Monomorphizing all mentioned names (enough to flush middleend post-mono errors) should fundamentally resolve the issue of constant evaluation errors disappearing because of MIR-level dead code elimination.

[joshtriplett]

@RalfJung Is it possible to produce a similarly horrifying example as #107503 (comment) that compiles on stable today, and is optimization-dependent and DCA dependent?

[RalfJung]

@joshtriplett yes. It's not even that hard.

pub fn cause_late_error<T>() {
    struct S;
    impl S {
        const C: () = panic!();
    }

    S::C;
}

fn main() {
    let a = 1;
    let b = 2;
    if a + b == 5 { // changing 5 to 3 makes compilation fail
        cause_late_error::<()>();
    }
}

[RalfJung]

And of course that also works for @oskgo's example:

#[inline(always)]
fn falser() -> bool {
    false
}

pub fn has_late_error<T>() {
    struct S;
    impl S {
        const C: () = panic!();
    }

    S::C;
}

fn main() {
    if falser() {
        has_late_error::<()>();
    }
}

Compiles in release mode but not in debug mode.

[zirconium-n]

Sorry if this sounds rude, but could we just issue a crater run and push a breaking change at this point? Panic in consteval is not something stabilized for too long. We can recognize this¹ as a design mistake. Whether the code depends on something other than #[cfg(debug_assertions)] is a bit too far for me...

Footnotes

1. Unused associated const doesn't not evaluate. ↩