Inline const errors are opt-level-dependent

[atynagano]

I tried this code:

fn inline_const() {
    const { panic!() }
}
pub fn main() {
    inline_const();
}

fn inline_const_with_const_generics_and_println<const N: i32>() {
    const { panic!() }
    println!();
}
pub fn main() {
    inline_const_with_const_generics_and_println::<0>();
}

fn inline_const_with_const_generics<const N: i32>() {
    const { panic!() }
}
pub fn main() {
    inline_const_with_const_generics::<0>();
}

fn inline_const_with_type_generics<T>() {
    const { panic!() }
}
pub fn main() {
    inline_const_with_type_generics::<i32>();
}

fn inline_const_with_const_generics_and_return<const N: i32>() -> Result<(), Box<dyn std::error::Error>> {
    const { panic!() }
    Ok(())
}
pub fn main() -> Result<(), Box<dyn std::error::Error>> {
    inline_const_with_const_generics_and_return::<0>()
}

I expected to see this happen:

The compile error should always occur, regardless of opt-level

error[E0080]: evaluation panicked: explicit panic
 --> repro.rs:3:13
  |
3 |     const { panic!() }
  |             ^^^^^^^^ evaluation of `inline_const::{constant#0}` failed here

note: erroneous constant encountered
 --> repro.rs:3:5
  |
3 |     const { panic!() }
  |     ^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0080`.

Instead, this happened:

	opt=0	opt=1	opt=2	opt=3	opt=3 (bin)	opt=3 (inline-mir=no)
inline_const	ERROR	ERROR	ERROR	ERROR	ERROR	ERROR
inline_const_with_const_generics_and_println	ERROR	ERROR	ERROR	ERROR	ERROR	ERROR
inline_const_with_const_generics	ERROR	ERROR	pass	pass	ERROR	ERROR
inline_const_with_type_generics	ERROR	ERROR	pass	pass	ERROR	ERROR
inline_const_with_const_generics_and_return	ERROR	ERROR	pass	pass	ERROR	ERROR

rustc --edition 2024 -C opt-level=0 --crate-type lib --emit=obj -o out.o repro.rs
rustc --edition 2024 -C opt-level=1 --crate-type lib --emit=obj -o out.o repro.rs
rustc --edition 2024 -C opt-level=2 --crate-type lib --emit=obj -o out.o repro.rs
rustc --edition 2024 -C opt-level=3 --crate-type lib --emit=obj -o out.o repro.rs
rustc --edition 2024 -C opt-level=3 --crate-type bin --emit=obj -o out.o repro.rs
rustc +nightly --edition 2024 -C opt-level=3 -Z inline-mir=no --crate-type lib --emit=obj -o out.o repro.rs

Meta

rustc --version --verbose:

rustc 1.97.1 (8bab26f4f 2026-07-14)
binary: rustc
commit-hash: 8bab26f4f68e0e26f0bb7960be334d5b520ea452
commit-date: 2026-07-14
host: x86_64-pc-windows-msvc
release: 1.97.1
LLVM version: 22.1.6

The issue also reproduces with rustc 1.99.0-nightly (ad3d0bc14 2026-07-31).

Related

• Const-eval errors in dead functions are optimization-dependent #107503
• recursively evaluate the constants in everything that is 'mentioned' #122568

Note

While I used an LLM to investigate this issue and perform machine translation, I myself conducted the issue reproduction and original text creation, as required by the Rust LLM Usage Policy, which I note here.

[theemathas]

This is known behavior. See discussion at 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/591461171

[theemathas]

Do you have a particular use case that relies on this behavior being a certain way?

[atynagano]

@theemathas I don't have a particular use case that depends on this behavior. I happened to notice it while using Rust, and since #107503 was closed and I couldn't find any open issue tracking the same behavior, I thought it might be an unresolved regression or a gap in test coverage.

[RalfJung]

The only guarantee we make is that we will not generate a binary that may execute inline_const_with_type_generics without evaluating the const. Whether the const is evaluated in the lib crate or whether that is delayed until a bin crate is built is not defined. So this behavior, while surprising, is currently expected. In practice the delay depends on the size of the function (which in turn impacts inlining heuristics), which is why adding println! changes behavior. Cc @saethlin

Cc @rust-lang/lang for some input on whether this seems fine. Relevant example code:

fn inline_const_with_type_generics<T>() {
    const { panic!() }
}
pub fn main() {
    inline_const_with_type_generics::<i32>();
}

When building this as a lib crate with high opt level, we don't monomorphize anything and hence don't evaluate the const block. When building this as a bin crate we obviously have to actually codegen main and then we start monomorphizing and we do evaluate the const block.

A while ago we spent some effort to make compilation success not depend on opt-level, but that only really applies to actually building a binary. When building a library, the set of things we monomorphize is much less constrained so behavior has more chances to diverge. To fix this we'd have to to a light form of monomorphization (looking for constants that are mentioned here, including recursively inside callees) even for functions like main that we mark as inlineable. That may have non-trivial performance impact, but we don't have numbers at the moment.

[tmandry]

We discussed this today in the lang team meeting. We accept the behavior documented in this issue as correct, albeit not optimal. We previously discussed and approved it around the stabilization of inline const; see #104087 (comment).

We'll leave it up to compiler team if they want to leave this issue open to track changes or improvements here.