ICEs on `#[loop_match]` with constant evaluation

[CrazyboyQCD]

Basic Code

#![feature(loop_match)]

#[unsafe(no_mangle)]
pub fn break_on_constant_evalution() -> i32 {
    let mut state = 0;
    #[loop_match]
    'a : loop {
        state = 'blk: {
            match state {
                0 => {
                    break 'a;
                },
                _ => {
                    const A: i32 = 0;
                    #[const_continue]
                    break 'blk /* constant evaluation */;
                }
            }
        }
    }
    state
}

• constant operation statment: https://godbolt.org/z/qcsKdqb7a (expression is not a valid constant Binary)
• const fn call: https://godbolt.org/z/dWaYoP9GE (expression is not a valid constant Call )
• const block: https://godbolt.org/z/zvs9ePzdj (cycle detected when building MIR for break_on_constant_evalution)

[RalfJung]

constant operation statment: https://godbolt.org/z/qcsKdqb7a (expression is not a valid constant Binary)

I think this is expected -- you must use a constant here, not some expression composed of constants. Let's not go down the rabbit hole of introducing a new class of "simple expressions" that can be accepted here, that way lies madness. Just use a const block instead.

const fn call: https://godbolt.org/z/dWaYoP9GE (expression is not a valid constant Call )

This is not a bug but entirely expected. The fact that the function is const fn makes no different whatsoever unless you try to call it in a const or const fn. (IOW: const fn means "you have permission to call this in const context", it does not mean "will be const-evaluated no matter where it is called".) Use a const block if you actually want something to be const-evaluated.

const block: https://godbolt.org/z/zvs9ePzdj (cycle detected when building MIR for break_on_constant_evalution)

This is how I would suggest to write code of this form, so I agree this one should be accepted.

[folkertdev]

This is how I would suggest to write code of this form, so I agree this one should be accepted.

I totally agree, but don't understand why that error occurs. We just call .as_constant, apparently that is not the right approach?

rust/compiler/rustc_mir_build/src/builder/scope.rs

Line 890 in 8df4a58

_ => self.as_constant(&self.thir[value]),

[RalfJung]

Turns out const { ... } also cannot work, for the same reason they do not work as patterns -- the variant to jump to must be known during MIR building, which is too early to evaluate const { ... } blocks.