`ref` patterns can const-promote a single constant more than once, and can both const-promote and move from the same value.

[theemathas]

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

I tried this code:

#![allow(dead_code)]

struct NotCopy { data: i32 }

fn main() {
    let ref x @ ref y = NotCopy { data: 1 };
    assert!(std::ptr::eq(x, y));
}

I ran the above code in Miri. The assertion failed.

It seems to me that the NotCopy constant is const-promoted twice, resulting in two implicit NotCopy statics. (I'm guessing that, outside of miri, the consts happen to be deduplicated.)

As a result, it is observable whether const promotion happened or not. In my understanding, promotion is supposed to happen only when it's not observable whether it has happened. Therefore, I think this behavior is incorrect.

See also #145237, where a constant is both moved and promoted.

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

Meta

Reproducible on the playground in version 1.91.0-nightly (2025-08-17 425a9c0a0e365c0b8c6c)

[traviscross]

See also:

• Promotion introduces UB into otherwise well-defined code unsafe-code-guidelines#493

Looking at the promotion text in the const-eval repo, regarding named locals,

Promotable expressions cannot refer to named locals. This is not a technical limitation with the CTFE engine. While writing let x = {expr} outside of a const context, the user likely expects that x will live on the stack and be initialized at run-time. Although this is not (to my knowledge) guaranteed by the language, we do not wish to violate the user's expectations here.

the behavior here does seem maybe to push against the spirit of that. If we assume that the let initializer is runtime-initialized and lives on the stack, it'd be surprising for two references to it to point to different places.

What do you think, @RalfJung, is this a new reason to want rid of implicit promotion?

[theemathas]

Another case:

use std::ptr;

fn main() {
    let [ref x, ref y] = [0u8; 2];
    assert!(ptr::eq(ptr::from_ref(x).wrapping_add(1), y));
}

The assertion fails on miri.

Changing one of the refs to ref mut causes the assertion to pass on miri.

[RalfJung]

As a result, it is observable whether const promotion happened or not. In my understanding, promotion is supposed to happen only when it's not observable whether it has happened. Therefore, I think this behavior is incorrect.

In general we exclude address identity from this requirement -- otherwise, we already violate this condition, since e.g. &0 in two different functions can be promoted and deduplicated, even though a "naive" semantics would never give them the same address.

However, for two references to the same place, such as in this case, this might be more surprising. I wonder if there's any other assumptions on promotion or const-checking that can be violated with such a "double-ref" pattern.

From a lang perspective, the more confusing case IMO is this:

#![allow(dead_code)]

fn main() {
    let ref x @ nc = 1;
    assert!(std::ptr::eq(x, &nc));
}

ISTM we are explicitly asking for a reference to nc here, but that's not what we end up getting... this assertion fails even outside Miri.

[traviscross]

Restating that in terms of its effect:

fn main() {
    let ref mut x @ mut _v = 0u8;
    _v = 1;
    *x = 2;
    assert_eq!(_v, 1);
    assert_eq!(*x, 2);
}

[RalfJung]

Uh, wait, what is going on there? That can't be promotion (we don't do that for mutable references, except &mut []). And it's not even about address identity any more. That definitely should be rejected, IMO.

[theemathas]

That's temporary lifetime extension, not promotion. let a = &mut 1; is accepted, and lifetime-extends the 1.

I'd assume it only works on Copy types.