Annotating the type of transmute of a const causes a reborrow and retag, increasing the amount of UB

[theemathas]

I tried this code:

use std::mem::transmute;
const A: &u8 = unsafe { transmute(&0u64) };
fn main() {
    // This is ok
    let _x: &u64 = unsafe { transmute::<_, _>(A) };
    // We can even read through the reference
    let _y = *_x;
    // This is UB
    let _z: &u64 = unsafe { transmute::<&_, _>(A) };
}

I expected the transmutes to either be both OK or both UB. Instead, only the second transmute is detected as UB by Miri.

error: Undefined Behavior: trying to retag from <298> for SharedReadOnly permission at alloc3[0x1], but that tag does not exist in the borrow stack for this location
 --> src/main.rs:9:29
  |
9 |     let _z: &u64 = unsafe { transmute::<&_, _>(A) };
  |                             ^^^^^^^^^^^^^^^^^^^^^ this error occurs as part of retag at alloc3[0x0..0x8]
  |
  = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
  = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <298> was created by a SharedReadOnly retag at offsets [0x0..0x1]
 --> src/main.rs:9:48
  |
9 |     let _z: &u64 = unsafe { transmute::<&_, _>(A) };
  |                                                ^
  = note: BACKTRACE (of the first span):
  = note: inside `main` at src/main.rs:9:29: 9:50

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

The relevant MIR is:

    bb0: {
        _1 = const A as &u64 (Transmute);
        _2 = copy (*_1);
        _4 = const A;
        _3 = move _4 as &u64 (Transmute);
        return;
    }

It seems to me that:

• The A const has provenance that can access the entire 8 bytes of the u64.
• transmute is not a typed copy, so it preserves that provenance when the type isn't annotated
• Annotating the type, for some reason, causes a typed copy of A to happen before transmuting, shrinking the provenance.

(Note that other means of causing a typed copy, such as adding a brace so it's transmute::<_, _>({A}), also causes UB.)

See also #143671 and #140123, where annotating a type changes the behavior of the program.

Meta

Reproducible on the playground with Rust version 1.92.0-nightly (2025-09-21 9f32ccf35fb877270bc4) and Miri version 0.1.0 (2025-09-21 9f32ccf35f)

[oli-obk]

Haven't checked anything yet, but my first guess is that we also generate debuginfo for _4, and that is what causes this.

One thing to investigate is whether it's not actually the other way around and not doing a typed copy is the "bug" (It's basically a UB hiding optimization)

[RalfJung]

In terms of what happens in Miri, it's not really about typed copies, it's about retags (which are separate operations in Miri). Arguably under SB the first one should also be UB, but we don't do any alias tracking during const-eval.

I assume in the 2nd version, the & annotation causes MIR building to insert a reborrow which will then come with a retag.

Here's the MIR as Miri sees it (-Zmir-opt-level=0 -Zmir-emit-retag):

    bb0: {
        StorageLive(_1);
        _1 = const A as &u64 (Transmute);
        Retag(_1);
        StorageLive(_2);
        _2 = copy (*_1);
        StorageLive(_3);
        StorageLive(_4);
        StorageLive(_5);
        _5 = const A;
        Retag(_5);
        _4 = &(*_5);
        _3 = move _4 as &u64 (Transmute);
        Retag(_3);
        StorageDead(_5);
        StorageDead(_4);
        _0 = const ();
        StorageDead(_3);
        StorageDead(_2);
        StorageDead(_1);
        return;
    }