Does `&raw const/mut $path` invalidate mutable references

[chorman0773]

Here is a formal aliasing model question. It seems like this should be easy - I'm pretty sure the answer is guaranteed to be yes on TB, though it is currently no on SB.

Basically, if you have an outstanding mutable reference to some memory region, then use &raw mut $path to get a raw pointer to the same memory, but do not dereference it (for example, calling .addr() on the pointer), does this invalidate the outstanding mutable reference?

I'm using this currently as a form of thread id on a thread_local value, while initializing the same value.

[RalfJung]

Basically, if you have an outstanding mutable reference to some memory region, then use &raw mut $path to get a raw pointer to the same memory

Where (which existing reference / pointer, and how is it related to the aforementioned "outstanding mutable reference") are you getting the raw pointer from?
Please give a concrete example.

[chorman0773]

#[thread_local]
static mut GENBYTES: OnceCell<Shake256Reader> = OnceCell::new();

#[unsafe(no_mangle)]
unsafe extern "C" fn fill_random_bytes(arr: *mut u8, len: usize) {
    let slice = unsafe { core::slice::from_raw_parts_mut(arr, len) };

    let generator = unsafe {
        (*&raw mut GENBYTES).get_mut_or_init(|| {
            let arr = get_auxval(AT_RANDOM).cast::<[u8; 16]>();
            let mut base = Shake256::default();
            base.update(&*arr);
            // Ensure that, if we're spawned via the system call, we generate a unique random sequence anyways.
            let gen_addr = (&raw mut GENBYTES).addr() as u128;
            let grandom =  common::arch::fast_random()  as u128;
            
            let arr = (gen_addr | (grandom << 64)).to_ne_bytes();

            base.update(&arr);

            base.finalize_xof()
        })
    };
    generator.read(slice);
}

Here is the code I'm doing. They both originate from the same Root (the GENBYTES thread_local)

[RalfJung]

So to make sure I understand correctly:

1. you're creating a raw ptr to GENBYTES
2. you're turning that into a mutable references (implicitly, as part of the call to get_mut_or_init)
3. you're creating another raw ptr to GENBYTES but the only thing you ever do with it is addr()
4. you're using the mutable references created in step 2

That's fine under Tree Borrows at least, step 3 is a NOP from the aliasing model perspective. Only accesses and references matter. Raw pointers not used for accesses are irrelevant.

[chorman0773]

Yeah, I was pretty sure it would be fine under TB. It would be nice to have a guarantee that it is fine period, whatever aliasing model we adopt.