`&raw const` gets static-promoted in match guard

[theemathas]

I tried this code:

static X: &i32 = unsafe {
    let wut = &*'a: {
        match one() {
            temp if { break 'a &raw const temp } => {}
            _ => {}
        }
        loop {}
    };
    wut
};

const fn one() -> i32 {
    1
}

fn main() {
    println!("{X}");
}

I expected some kind of error, possibly UB. Instead, the code runs fine and prints 1.

It seems that the &raw const temp is somehow causing temp to be lifetime-extended. This seems wrong. Only non-raw referencing should cause lifetime extension or static promotion.

See also #142229, where a similar weirdness causes an ICE. cc @RalfJung

This issue was discovered jointly with @danielhenrymantilla

@rustbot labels +A-const-eval +A-patterns

Meta

Reproducible on the rust playground with version 1.91.0-nightly (2025-08-03 f34ba774c78ea32b7c40)

[theemathas]

And here's a version that shows static promotion. (Miri indicates no UB.)

fn foo() -> &'static i32 {
    unsafe {
        &*'a: {
            match 1 {
                temp if { break 'a &raw const temp } => {}
                _ => {}
            }
            loop {}
        }
    }
}

fn main() {
    println!("{}", foo());
}

[traviscross]

Consider:

const _: () = {
    struct S;
    const fn g() -> S { S }
    match g() {
        x if { let _: &'static _ = &x; true } => {}
        _ => {}
    }
};

fn _f1() {
    match None::<String> {
        x if { let _: &'static _ = &x; true } => {}
        _ => {}
    }
}

As described in #145237 (comment), the promotion is being triggered simply by the presence of the guard, not by the borrow in the guard or by the raw borrow in the earlier examples in this issue.

In terms of why the call to g() is promoted in the first example, the const-eval promotion document explains this:

There is one exception to this rule [about not promoting arbitrary calls to const functions]: the bodies of const/static initializers. This code is never compiled, so we do not actually have to evaluate constants that occur in dead code. If we are careful enough during compilation, we can ensure that only constants whose value is actually needed are evaluated. We thus can be more relaxed about promotion; in practice, what this means is that we will promote calls to arbitrary const fn, not just thosemarked #[rustc_promotable].

[RalfJung]

It seems that the &raw const temp is somehow causing temp to be lifetime-extended. This seems wrong. Only non-raw referencing should cause lifetime extension or static promotion.

Cc @m-ou-se @oli-obk for lifetime extension and promotion expertise.
I am currently clueless about what actually happens in this example...

And here's a version that shows static promotion. (Miri indicates no UB.)

Here's a variant of that without promotion, so this one has to be lifetime extension (but your example is indeed promotion, I checked the MIR):

struct NoPromote(i32);

impl Drop for NoPromote {
    fn drop(&mut self) {}
}

fn foo() -> &'static NoPromote {
    unsafe {
        &* 'a: {
            match NoPromote(1) {
                temp if { break 'a &raw const temp } => {}
                _ => {}
            }
            loop {}
        }
    }
}