Which functions are "reachable", and therefore subject to monomorphization-time checks, is optimization-dependent

[RalfJung]

This is a variant of #107503, but with a different underlying cause and hence not fixed by #122568. @tmiasko provided this magnificent example (comments by me, they may be wrong):

//! This used to fail in optimized builds but pass in unoptimized builds. The reason is that in
//! optimized builds, `f` gets marked as cross-crate-inlineable, so the functions it calls become
//! reachable, and therefore `g` becomes a collection root. But in unoptimized builds, `g` is no
//! root, and the call to `g` disappears in an early `SimplifyCfg` before "mentioned items" are
//! gathered, so we never reach `g`.
#![crate_type = "lib"]

struct Fail<T>(T);
impl<T> Fail<T> {
    const C: () = panic!(); //~ERROR: evaluation of `Fail::<i32>::C` failed
}

pub fn f() {
    loop {}; g()
}

#[inline(never)]
fn g() {
    h::<i32>()
}

// Make sure we only use the faulty const in a generic function, or
// else it gets evaluated by some MIR pass.
fn h<T>() {
    Fail::<T>::C;
}

The symptom here is the opposite of #107503: cargo build succeeds but cargo build --release fails. This is because more things become roots in optimized builds and therefore we evaluate more things.

I can think of two ways of fixing this:

• Making the set of collection roots opt-level-independent. This is what I tried in a303df0. It caused a ~2% slowdown on some benchmarks; it's hard to get the full picture as we only benchmarked it together with the rest of recursively evaluate the constants in everything that is 'mentioned' #122568. There may be ways to reduce this cost.
• Make sure g is considered "mentioned" in f. This requires either collecting (some of) the mentioned items very early during MIR building, or making SimplifyCfg preserved unreachable blocks. This likely has lower perf impact, but it means we'd still miss const-eval failures reachable from dead private monomorphic functions.

[tmiasko]

The second approach is insufficient to resolve this issue.

Consider the example below or anything else that takes advantage of the fact that reachability is a static conservative over-approximation of the actual mono item collection.

#![crate_type = "lib"]
#![feature(inline_const)]

pub fn f() -> fn() {
    loop {}; const { g::<()>() }
}

const fn g<T>() -> fn() {
    match std::mem::size_of::<T>() {
        0 => ga as fn(),
        _ => gb as fn(),
    }
}

#[inline(never)]
fn ga() {
}

#[inline(never)]
fn gb() {
    if false { const { 1 / 0 }; }
}

[RalfJung]

Ah, I see. We'd have to walk the mentioned items of constants we encounter as well, then. Can a similar example be constructed based on all trait impl fn being considered reachable?

[tmiasko]

All trait impls being reachable seems like a non-issue, because they are only used to seed an initial set of items. At this stage of computation there is no optimization level dependency yet.

[RalfJung]

@tmiasko can you turn your example above into a testcase that actually demonstrates opt-dependent behavior? I tried and failed.

[tmiasko]

Sure, I edited the comment by adding an erroneous constant to gb (it is behind and if false { ... } as otherwise it would be eagerly evaluated by KnownPanicsLint).