Is `rustc` allowed to skip constant evaluation if it thinks the constant is unreachable? Under what circumstances?

help
1

This fails to compile, which matches my expectation:

// (!) fails to compile
fn main() {
    const { panic!() } // error[E0080]: evaluation panicked: explicit panic
}

But if we make it unreachable after a runtime panic, it compiles, which is surprising to me:

// compiles !?
fn main() {
    panic!();
    const { panic!() }
}

Buf if we make it unreachable on a compile-time condition, it goes back to failing compilation:

// (!) fails to compile
fn main() {
    if false {
        const { panic!() } // error[E0080]: evaluation panicked: explicit panic
    }
}

I couldn't find anything in the reference/const_eval about this.

Aside from being personally surprising, I suspect this would break code that was doing clever comptime assertions that might be skipped following a panic.

2 
$ rustc --version
rustc 1.89.0 (29483883e 2025-08-04)

cd $(mktemp -d)
cargo init --name bikeshed .
rm src/main.rs
mkdir src/bin
cat <<EOF > src/bin/straight.rs
fn main() {
    const { panic!() }
}
EOF
cat <<EOF > src/bin/after-panic.rs
fn main() {
    panic!();
    const { panic!() }
}
EOF
cat <<EOF > src/bin/after-false.rs
fn main() {
    if false {
        const { panic!() }
    }
}
EOF
3

Const assert is not evaluated in const generic unless used is related

4

That page is about constant evaluation in general, but what you have in your examples is specifically a const block expression, for which it says:

If the const block expression is not executed at runtime, it may or may not be evaluated

A const block expression is guaranteed to be evaluated if it would be reachable at runtime, so unsafe code can rely on const assertions executed just before.

2 Likes
5

I don't know the exact rules, but note that these two examples are very different from the type system point of view:

panic!() diverges unconditionally; its return type is !.

Even though the condition is known to be false at compile time, the if statement is not in a compile-time eval context. From the type system POV the condition has the type bool which means it might be true or it might not, and there's no type in Rust that encodes "bool that's exactly true" (this is what dependent/refinement/flow/pattern types are about). It doesn't matter that the branch is "obviously" not taken (and the optimizer would trivially remove the whole statement), the compiler doesn't mix and match compile-time and run-time semantics like that.

On the other hand, this compiles as expected:

fn main() {
    const {
        if false {
            panic!()
        }
    }
}

(OTOH if we start nesting consts[1], it stops compiling again. A const context nested inside a const context is a "deeper level" of constness in a sense. Meta-constant if you will.)

fn main() {
    const {
        if false {
            const { panic!() }
        }
    }
}

  1. constception! ↩︎

1 Like
6

panic!() expands to a function with a ! return type. This is a compile-time property. The function guarantees to never return, and the compiler doesn't need to run it to know it.

1 Like
7

As you have found, there is nothing in The Reference that states unreachable code in const "contexts" may not be evaluated at compilation time; thus I think you should submit a PR. If this were a less "precise" document, then I suppose I could forgive the omission; but I think it's appropriate for The Reference to be precise especially since the fix is so small. Specifically I'd change this (emphasis added):

In const contexts, these are the only allowed expressions, and are always evaluated at compile time.

to this:

In const contexts, these are the only allowed expressions; and if reachable, are always evaluated at compile time.

You could argue that your if false example is not "reachable", so perhaps being more specific like:

In const contexts, these are the only allowed expressions and are always evaluated at compile time unless unconditionally unreachable.

Tangentially related, you can deny unreachable_code to ensure there is no code after a panic or use an actual constant since items live for the entire scope they are declared in. For example, the below does not compile:

fn main() {
    panic!("");
    const _: () = panic!("");
}
8

I think the lang and compiler teams don't want to make any promises that if not reachable, they won't be evaluated — the lack of evaluation is a compromise for compiler performance, not a desirable property. Also, "if reachable, are always evaluated at compile time" could be read as "if not reachable, may be evaluated at run time". There’s two different meanings of “always” here. What should be specified is:

If [one of these expressions] is evaluated, then that evaluation will occur at compile time.

1 Like
9

Currently constants aren't evaluated for generics that aren't monomorphized, whether that's guaranteed is an open question, see

10

My wording was not clear then. The "unless unconditionally unreachable" was not meant as "guaranteed to not be evaluated at compilation time" but instead that the guarantee of it being evaluated at compilation time no longer holds. The fact the compiler can evaluate non const contexts at compilation time is clearly true seeing how it's not difficult to get a let item to cause a compilation failure despite it not being a const context.

11

Indeed. I have been bitten by that in the past forcing me to either document that a panic may occur or return an Option to guarantee that a panic won't occur.

12

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.