GVN makes some post-monomorphisation errors optimisation-dependent

[narpfel]

Code

I tried this code (https://rust.godbolt.org/z/EdW33qf15):

use std::marker::PhantomData;

pub fn f<T>() -> bool {
    struct Panic<T>(PhantomData<T>);

    impl<T> Panic<T> {
        const PANIC: bool = panic!();
    }

    Panic::<T>::PANIC
}

I expected to see this happen: I expect the panic to be a post-monomorphisation error, i. e. compilation should succeed because f is never monomorphised. This should be independent of the optimisation level.

Instead, this happened: This errors with -C opt-level=3, but not with -C opt-level=0.

This seems to be caused by a change in the GVN MIR opt between 1.74 and 1.75; the error can be reproduced by -Z mir-enable-passes=+GVN on 1.75 (but not 1.74).

I originally noticed this with an inline const block, which shows the same change between 1.74 and 1.75 with GVN enabled (https://rust.godbolt.org/z/xxGTjjvYn):

pub fn f<T>() -> bool {
    const { panic!() }
}

Version it worked on

It most recently worked on: Rust 1.76 (Rust 1.74 with -Z mir-enable-passes=+GVN)

Version with regression

It regressed in Rust 1.75 with -Z mir-enable-passes=+GVN.

GVN was enabled by default for 1.77 for opt-level != 0:
a03c972#diff-6202eda9e5f3c8b8a291cf165920ea8484c372002e485eafa920b319f7cb4dd3L112-R112

rustc --version --verbose:

rustc 1.77.0 (aedd173a2 2024-03-17)
binary: rustc
commit-hash: aedd173a2c086e558c2b66d3743b344f977621a7
commit-date: 2024-03-17
host: x86_64-unknown-linux-gnu
release: 1.77.0
LLVM version: 17.0.6

Backtrace

Backtrace

<backtrace>

[workingjubilee]

It is not, to my awareness, possible to avoid post-monomorphization errors being sometimes-optimization-dependent in the fully general case?

...That is not to say that your expectation here is invalid, so thank you for reporting this. This seems like an interestingly simple example.

[theemathas]

See also https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const-eval.20does.20not.20try.20to.20monomorphize.20the.20whole.20call.20graph/near/591668746 which has the opposite behavior of compiling in release but erroring in debug.

[apiraino]

backlinking #116012 where this was introduced 3 years ago

[cjgillot]

I'm not sure which should be the proper behavior. If we were rigorous, we would error in both cases. Is this what we want?

[theemathas]

cc @oli-obk @saethlin