`#[inline]` affects whether consteval happens

[theemathas]

I tried this code:

fn foo<T>() {
    const { panic!() }
}

// uncommenting this line makes it compile
// #[inline]
pub fn wut() {
    foo::<i32>();
}

I expected #[inline] to not affect whether the code compiles or not. However, the code compiles with #[inline], and fails to compile without #[inline]. I'm not sure if this is a bug or not.

Discovered in #144363

@rustbot labels +A-const-eval

Meta

Reproducible on the playground with stable rust 1.88.0

[rustbot]

Unknown labels: A-consteval

[RalfJung]

Yeah this is expected, const-eval of inline consts happens during monomorphization and inline delays monomorphization.

So, no, not a bug.

[saethlin]

Almost like we need a C-confusing-semantics

[oli-obk]

I guess we could still evaluate the required consts of code reachable from public inline functions

[theemathas]

Note: this currently doesn't compile

#[inline]
pub fn wut() {
    const { panic!() };
}

[saethlin]

Indeed, the semantics are very confusing.

[RalfJung]

Note: this currently doesn't compile

#[inline]
pub fn wut() {
const { panic!() };
}

Yeah, monomorphic functions are treated differently.

Indeed, the semantics are very confusing.

Fully agreed. Some time last year I tried to make them less confusing but hit a perf wall every single time, and eventually gave up. So right now the semantics are:

• Every function that actually runs definitely had all its inline consts evaluated at some point during compilation.
• Whether or not optimizations are turned on mostly does not affect which consts are evaluated (but there's an issue somewhere because this is not fully true at the moment)

That's it, everything else is unspecified and can change any time.

[xonx4l]

I tried to reproduce the error but it compiles fine in both nightly and stable rust .