mark &mut parameters noalias if there are no potentially aliasing parameters

[thestinger]

&mut can alias with &const, @mut, other types like @mut that allow a &mut borrow while still allowing reads and closures containing captured aliases.

[emberian]

Visiting for triage; nothing to add.

[thestinger]

There are too many special cases involved here, so this really requires type-based alias analysis.

[thestinger]

Note that the killer issue involves @mut pointers in task-local storage.

[huonw]

I don't understand why TLS @mut is any different to non-TLS @mut (or even TLS ~/non-pointer): they all still have dynamic borrow checks that stop aliasing, don't they?

[thestinger]

There is nothing stopping @mut from aliasing with &mut. There will just be a maximum of one alias at a time, which is not a good enough guarantee for this. TLS means it is not apparent from the function signature whether you could have an @mut able to alias the &mut.

[huonw]

There is nothing stopping @mut from aliasing with &mut

They might alias (i.e. point at the same memory), but if a @mut is borrowed as &mut there is no way to actually observe any changes to the contents of the @mut: the dynamic borrow check will prohibit all of them (without unsafe code, that is). Similarly for TLS, if it's been borrowed as &mut then the TLS dynamic borrow checker will fail on any attempt to access that piece of memory. I would think this satisfies the definition of LLVM's NoAlias (since the @mut pointer can never actually be dereferenced/read/written to).

fn at_and(x: &mut int, y: @mut int) {
    *x += 1;
    printfln!(*y);
}

fn at_at(x: @mut int, y: @mut int) {
     *x += 1;
    printfln!(*y);
}

fn main() {
    let x = @mut 1;
    at_at(x, x); // prints 2
    at_and(x, x); // the *y fails
}

That said, I agree that there are too many special cases for a simplistic implementation like this bug.

[nikomatsakis]

One danger is that you can still read from @mut, so LLVM must
still consider them as potentially aliasing.

[huonw]

Oh! printfln! decieved me: %? it clearly reborrows its argument by calling .repr(), so it's performing an & borrow (i.e. the printfln!(*y) is effectively &*y) not a plain dereference.

(I retract what I said above about @mut (including in TLS); but not about TLS in general, since all the ways to access it fail if the value has already been borrowed via get or get_mut.)

[eddyb]

Is there still a problem, given @mut is gone from the language? Also, can't we annotate &T with T: Freeze with another attribute, as well?

[alexcrichton]

This may still be a problem with RefCell, but I don't actually think that it is because you can't get two aliasing &mut pointers out of a RefCell (whereas with @mut you could have two aliasing pointers, they just have different types with one as &mut and one as @mut

[thestinger]

I guess this might be possible again. It requires input from @nikomatsakis or @pcwalton because I don't know whether there are any plans to have borrows aliasing with unchecked plain old data reads again.

[nikomatsakis]

In my branch addressing #2202, closures could sometimes produce the equivalent of &const pointers, but those were not user-visible. Otherwise I think the current plan is to try and hold the line against &const and stick to mutable or immutable.

[nikomatsakis]

Still, I wonder if when it comes to Cell we must still be careful. It is true that you cannot have a &mut and a & pointer derived from the same cell simultaneously, but you can have them in sequence, so they still interfere with one another.

[nikomatsakis]

same for RefCell

[nikomatsakis]

I guess though that we can apply aggressive mutability annotations so long as the types are not considered to be mutable.

[thestinger]

Duplicate of #12436.