Rust needs a memory model

[pnkfelix]

As noted by @arielb1, we need an organized place for resolving questions about the Rust memory model.

While I could have made this a post on internals.rust-lang.org, I think this topic 1. needs visibility, and 2. needs to be able to be easily cross-referenced by the other issues and discussions that are hosted on github.

Eventually such discussion will hopefully culminate in an actual RFC document with a definition of the Rust memory model.

So, this issue is meant to be a collecting place for either such discussion, (or linking other discussions that perhaps should funnel into here).

[pnkfelix]

cc rust-lang/rust#30424

[pnkfelix]

cc @arielb1 @nikomatsakis @RalfJung

[pnkfelix]

cc rust-lang/rust#9883

[pnkfelix]

see also https://internals.rust-lang.org/t/comparing-dangling-pointers/3019

[eddyb]

cc @ubsan

[RalfJung]

While writing rust-lang/rust#30424 (comment), some more general thoughts about the memory model came to my mind, so I'm now dropping them in this thread. (Note that in this context, the core purpose of the memory model is to define which programs have UB and which don't. At least that's my reading of it. There is probably little discussion about what the actual behavior of the program should be, if it has defined behavior.)

I am pretty worried about how sensitive the UB-related discussion we are having in rust-lang/rust#30424 is to the concrete lifetimes that the compiler infers. Considering that it has a lot of freedom in this inference (and it was able to surprise me with its results), the fact that whether a program has UB or not can depend on the assignment of lifetimes is... troublesome, to say the least. I don't think this should be the case. But I'm also not sure if it can be avoided. Depending on the goal that the memory model wants to achieve, it may be impossible to avoid.

Right now, the only goal I know of is "the noalias annotations should be correct", and since this restricts the entire story to function arguments which are the place where lifetimes are most explicit, we may be good (in the sense that, there may be a way to define things such that UB doesn't depend on the lifetimes anymore). But you may have optimizations in mind that need stronger guarantees.

It would be great if there was a write-up or something of the kind of assertions that you want to be "made true by introducing UB", and the program transformations that rely on these assertions (and that hence form the motivation). Such a document would form the design constraints a memory model has to satisfy. There is probably enough room for discussion already on these design constraints that it's a bad idea to start serious work on a detailed memory model before we know how it is supposed to behave ;-) . I also assume some of you guys have lots of intuition about this, and it would be tremendously helpful if that intuition could be documented.

[mahkoh]

Right now, the only goal I know of is "the noalias annotations should be correct", and since this restricts the entire story to function arguments

noalias annotations only being used for function arguments is an open bug.

[RalfJung]

See, that's what I meant ;-) . The way the semantics of noalias are defined in LLVM, I have no idea what, formally, noalias could mean anywhere else. (Except for return values, where they say it means the function is like malloc - which means this is no fit for functions returning &mut.)

[mahkoh]

It means that memory operations don't alias overlap.

unsafe fn f(x: *mut u8, y: *mut u8) -> u8 {
    let x = &mut *x;
    let y = &mut *y;
    *x = 1;
    *y = 2;
    *x
}

always returns 1.

[RalfJung]

That would be one of the examples for the aforementioned document :D . The idea here seems to be, two mutable references are disjoint.

What about this code?

unsafe fn f(x: *mut u8, y: *mut u8) -> u8 {
    let x = &mut *x;
    *x = 1;
    *y = 2;
    *x
}

Now the "overlapping" write happens through a raw pointer, not through a mutable reference.

[mahkoh]

It returns 1. Consider

unsafe fn f(x: *mut u8, y: *mut u8) -> u8 {
    unsafe fn g(x: &mut u8, y: *mut u8) -> u8 {
        *x = 1;
        *y = 2;
        *x
    }
    let x = &mut *x;
    g(x, y)
}

which returns 1 unconditionally.

The behavior must not be changed by this transformation.

[mahkoh]

The behavior must not be changed by this transformation.

Because otherwise safe code can become unsafe by either manually inlining a function or moving part of a function to another function.