Stacked Borrows and Tree Borrows both currently allow overlapping mutable references to be used, as long as they don't access the same memory

[ais523]

Both of Rust's aliasing models currently allow code like the following:

#[repr(align(4))]
#[derive(Debug)]
struct TwoU16s(u16, u16);

fn main() {
    let mut store = TwoU16s(10, 20);

    let ptr = &raw mut store;
    // create a unique reference to `store`
    let all = unsafe { &mut *ptr };
    *all = TwoU16s(30, 40);
    // create a second unique reference to one field of `store`
    let one = unsafe { &mut (*ptr).1 };
    // assign through each mutable reference during the lifetime of the other
    *one = 50;
    all.0 = 60;
    *one += 5;
    
    println!("{:?}", store);
}

This code creates two mutable references, all which refers to the whole of the object store and one which refers to a single field of it, and uses both references at the same time (because one is written through both before and after the write through all, both mutable references must be live at the same time). This is allowed by both Tree Borrows and Stacked Borrows (because the references access disjoint memory). However, it goes against most Rust programmers' mental models of how mutable references behave (because there are two simultaneously live mutable references to the same memory, neither of which is a reborrow of the other and both of which can be used without ending the lifetime of the other).

I'm primarily concerned about the disconnect between what appears to be currently permitted and what most Rust programmers would expect to be permitted – if the aliasing model deviates too far from what people would expect to be allowed, it may lead to them making unsound assumptions. (For example, on platforms where 32-bit writes are faster than 16-bit writes, a compiler operating on an intuitive idea of how mutable references work might assume that the write to all.0 might be more efficiently implemented by writing to the entirety of all, which might appear to have a known value (30, 40) at that point, but that would break code like the code above.)

Code like the code above might potentially be useful in practice – it makes it possible to get the correct provenance for writes to one when using strict provenance, in cases where you can statically prove that the memory behind one won't be written to (or given as a function argument) by other code, but can't prove that no mutable borrows of store exist (such a case actually came up for me recently, which is what prompted me to experiment with this sort of code). As such, there seem to be advantages to both intentionally allowing it (because it makes this sort of program easier to express with strict provenance), and intentionally disallowing it (because it allows more compiler optimisations). However, it's currently unclear whether it's been allowed intentionally or unintentionally, especially because it "looks like" a bug (even if it actually isn't).

(Split out from #133 – currently "spurious" writes through a mutable reference are not allowed, but if they were allowed, they would break code like this, and thus it would have to be considered illegal in order to be able to implement optimisations that relied on spurious writes.)

[RalfJung]

Thanks for filing an issue!

As far as I am concerned, this is fully deliberate; we should accept such code. These mutable references are used in disjoint ways, after all. The lifetime of all on field 1 ends when one gets created, but it remains a valid reference for field 0. A long time ago we considered tying the lifetimes of a reference together across all bytes, but a few experiments very quickly showed that this is incompatible with how raw pointers and references are used in practice. Sadly, I don't think we kept a record of any details here.

Is it fair to summarize your comment as "a reference should be fully invalidated once it gets invalidated anywhere"?

(Split out from #133 – currently "spurious" writes through a mutable reference are not allowed, but if they were allowed, they would break code like this

You seem to use a very wide definition of "spurious writes". SB allows the spurious writes discussed in #133, so what you are saying is that you want even more spurious writes than what #133 is about.

[ais523]

I would summarize my comment as "most Rust programmers expect a reference to be fully valid for reads and writes during its lifetime, and fully invalid after the lifetime" – the "partially valid reference" concept doesn't match anything that is possible in safe Rust, which is surprising for many Rust programmers because references are a safe-Rust concept. (A pointer that is valid for some bytes in its range but not others wouldn't be at all surprising.) This mostly agrees with your characterisation of it, except that I was focused more on programmer expectation than on the desired semantics (and am not sure whether or not changing the semantics would be desirable – I am not sure whether the advantages outweigh the disadvantages).

As such, I'm concerned that unless the concept is taught more clearly, it may cause programmers to write unsound code due to not expecting the possiblity. (For example, I originally assumed that because all.0 can be written to inside the lifetime of one, then all.1 can be written to after the lifetime of one – the mental model there would be "this is the same thing as reborrowing all.0 and all.1 from all with one taking the role of all.1" – but that is not how it actually works, so my assumption might have lead me to write unsound code.)

[ia0]

the "partially valid reference" concept doesn't match anything that is possible in safe Rust

it may cause programmers to write unsound code due to not expecting the possiblity

Based on those 2 sentences, I wonder if this is not an example of #561 where one can build a value that is valid but not safe. In your example that value would be all: &'a mut TwoU16s, because of the write through its second field through a different mutable pointer within the lifetime 'a inferred by the type system. So all is not a "safe" value (it is not in the safety invariant of &'a mut TwoU16s). Unsafe code is permitted to do that and this (sadly IMO) happens quite often, mostly because the type system is too weak to do otherwise in a readable manner. I agree with you that:

• This "partially valid reference" concept doesn't match anything possible in safe Rust.
• Programmers may not expect this possibility if they are used to think in safe Rust, where values are safe.

But on the other side, unsafe Rust programmers should not be surprised. This is a usual phenomenon for unsafe code to handle "unsafe values" (values that are valid but not safe). What matters is that unsafe code doesn't leak such values to safe code because that would be unsound. See also the unsafe mental model for a more detailed description of this phenomenon.