UB inconsistency when derefing a place in a closure

[Nadrieril]

This was initially reported as a Miri bug: rust-lang/miri#4258

Under Miri, these two uses of **r report inconsistent UB:

use std::mem::transmute;

fn main() {
    let r: &&u32 = unsafe {
        let x = 42;
        transmute(&&x)
    };

    // no UB detected
    let f = || { let _ = **r; };
    f();
    
    // UB due to the inner deref
    let _ = **r;
}

The closure capture rules consider the whole of **r to be a capture path, and says that "Closures only capture data that needs to be read". Given the rest of that section, it's fair to interpret the usage above as not reading data hence not requiring a capture. This is what the compiler does today.

But in the actual MIR lowering of the second case, we consider that the double-deref does constitute a read of the inner &u32, which triggers UB.

There's a tension here: the read of the inner &u32 doesn't matter in safe code, so I see why closure capture rules would consider that it doesn't matter. But this does introduce a surprising behavior difference. Can we resolve this somehow?

[RalfJung]

@rustbot label +I-lang-nominated

FWIW I would argue that let _ = **r "needs" to read *r to even be able to create the place **r, which is then discarded without being read from.