Match guard can both move and static-promote a single constant.

[theemathas]

I'm not sure if this is a bug or not.

I expected the below code to produce a compile error, but instead it compiles fine.

struct Thing;

fn foo() -> &'static Thing {
    let y;
    match Thing {
        x if { y = &x; true } => {
            // This drop should invalidate y
            drop(x);
            y
        }
        _ => {
            panic!();
        }
    }
}

It seems that the single Thing constant is both moved and static-promoted. This seems very strange.

Related to #144939. Discovered in #141295 (comment).

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

Meta

Reproduces on the playground with version 1.91.0-nightly (2025-08-09 ca77504943887037504c)

[kakserpom]

It doesn't compile if you add

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

error[E0505]: cannot move out of value because it is borrowed
  --> src/main.rs:8:9
   |
8  |         x if {
   |         ^
   |         |
   |         move out of value occurs here
   |         borrow of value occurs here
...
15 |             y
   |             - returning this value requires that borrow lasts for `'static`

[theemathas]

That's because values that implement Drop do not get static-promoted.

[kakserpom]

How about these? I got rid of 'static.

• (FAILS) impl Drop AND drop()
• (FAILS) impl Drop
• (OK) drop()

[theemathas]

I don't see how the lack of a 'static annotation changes anything about the issue. It's still static-promoted. 🤷

[kakserpom]

cargo clippy:

warning: call to `std::mem::drop` with a value that does not implement `Drop`. Dropping such a type only extends its contained lifetimes
 --> src/main.rs:8:13

So this doesn't look like a bug.

[theemathas]

drop() here can't change run time behavior, but it can change whether code compiles or not. I included it here as a stand-in for any operation that consumes x, to make it clearer that the code should not compile.

[dianne]

This does feel strange. Given that x is bound by-move, I'd expect there to be a move error from the scrutinee being moved into x after the guard succeeds. I feel like this may be a T-lang question: either this behavior should be specified as part of the language, or the language as defined by the compiler is too permissive.

Edit: relevant reference section: https://doc.rust-lang.org/reference/destructors.html#constant-promotion. The "without changing runtime behavior" is a bit funny, since it only applies vacuously here, given that it wouldn't compile if not for it being static-promoted in the guard and only the guard.

@rustbot label +T-lang +I-lang-nominated