3 ms·

Doesn't UnsafeCell only affect &T, not &mut T? &mut is always unique.

by Rusky 8y ago

steveklabnik 8y ago
It’s true that &mut T is always unique; restrict says “this does not alias”, which &Ts trivially do. It goes on &mut T. For example, see https://github.com/rust-lang/rust/pull/31545 https://github.com/rust-lang/rust/pull/31545, we had to remove this for a few releases due to an LLVM bug; it'll be back in the next release. It’s phrased in the reference as > &mut T and &T follow LLVM’s scoped noalias model, except if the &T contains an UnsafeCell. “noalias” is restrict here. But it’s not on &T, it’s the system as a whole that follows the guarantees, that is, both with and without. You still can’t have un-exclusive access with a &mut T. For more: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html (And see the stuff on that page about how some of this is still in flux. And, maybe I’ve made some mistake with my words here; this stuff is hard and not what I deal with day to day...)
- Rusky 8y ago
  Right, so if &mut is always unique anyway then the presence of an UnsafeCell shouldn't affect it, since it's about weakening guarantees. In fact, looking at the compiler output (https://godbolt.org/g/kt2xfW https://godbolt.org/g/kt2xfW), it looks like only &T has noalias, and not &mut T. It does go away in the presence of UnsafeCell, but for &mut T it was never there in the first place. So either that's a place where we can still add more noalias annotations, or it's off for some subtle reason I'm not familiar with.
  - steveklabnik 8y ago
    You won’t get the noalias stuff on &mut T until ththen next release, as I mentioned above, due to an LLVM bug.
    - Rusky 8y ago
      Ah, right; missed that part of what you were saying. If you switch the compiler version on my godbolt link to beta, the &mut i32 and &mut UnsafeCell<i32> both have the noalias attribute, so looks like it's on track. :)

Doesn't UnsafeCell only affect &T, not &mut T? &mut is always unique.

by Rusky 8y ago

Doesn't UnsafeCell only affect &T, not &mut T? &mut is always unique.

It’s true that &mut T is always unique; restrict says “this does not alias”, which &Ts trivially do. It goes on &mut T. For example, see https://github.com/rust-lang/rust/pull/31545 https://github.com/rust-lang/rust/pull/31545, we had to remove this for a few releases due to an LLVM bug; it'll be back in the next release. It’s phrased in the reference as > &mut T and &T follow LLVM’s scoped noalias model, except if the &T contains an UnsafeCell. “noalias” is restrict here. But it’s not on &T, it’s the system as a whole that follows the guarantees, that is, both with and without. You still can’t have un-exclusive access with a &mut T. For more: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html (And see the stuff on that page about how some of this is still in flux. And, maybe I’ve made some mistake with my words here; this stuff is hard and not what I deal with day to day...)

Rusky 8y ago
Right, so if &mut is always unique anyway then the presence of an UnsafeCell shouldn't affect it, since it's about weakening guarantees. In fact, looking at the compiler output (https://godbolt.org/g/kt2xfW https://godbolt.org/g/kt2xfW), it looks like only &T has noalias, and not &mut T. It does go away in the presence of UnsafeCell, but for &mut T it was never there in the first place. So either that's a place where we can still add more noalias annotations, or it's off for some subtle reason I'm not familiar with.
- steveklabnik 8y ago
  You won’t get the noalias stuff on &mut T until ththen next release, as I mentioned above, due to an LLVM bug.
  - Rusky 8y ago
    Ah, right; missed that part of what you were saying. If you switch the compiler version on my godbolt link to beta, the &mut i32 and &mut UnsafeCell<i32> both have the noalias attribute, so looks like it's on track. :)