Tracking Issue for RFC 3467: UnsafePinned

[traviscross]

This is a tracking issue for RFC 3467: UnsafePinned.

• UnsafePinned: allow aliasing of pinned mutable references rfcs#3467

The feature gate for the issue is #![feature(unsafe_pinned)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Accept an RFC.
  • UnsafePinned: allow aliasing of pinned mutable references rfcs#3467
• Implement.
  • Initial UnsafePinned implementation [Part 1: Libs] #137043
  • UnsafePinned: also include the effects of UnsafeCell #140638
  • Initial UnsafePinned implementation [Part 2: Lowering] #139896
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Stabilize.

Unresolved Questions

• Do we want to bikeshed the name further before stabilization?
• Should &UnsafePinned permit mutation or not? Also see Decide what to do about UnsafePinned and safe Pin::as_ref #137750
• Which of Send, Sync, Copy, Clone should this type implement under which conditions? Also see this.
• Do we want to stabilize Freeze first? And what about the equivalent trait for &mut aliasing (UnpinUnsafe in the RFC)?
  • See: UnsafePinned: also include the effects of UnsafeCell #140638 (comment)

Related

• UnsafePinned: allow aliasing of pinned mutable references rfcs#3467

Implementation history

TODO.

[RalfJung]

Turns out the existing hack that attempts to make self-referential async lowering sound is incomplete, and we most likely need UnsafePinned to make it actually sound.

[RalfJung]

In the RFC we had the question whether UnsafePinned should also act like an UnsafeCell. I am now fairly sure that the answer is "yes, it must". The reason is this: due to Pin::deref being safe, it is at any moment possible to create a shared reference to a future that is halted at a suspension point. If there is no UnsafeCell, this acts like a read of the entire future data, and that read conflicts with mutable references that the future may hold to its own data. This is not a necessary property of aliasing with mutable reference, but it is a necessary consequence of the decision that Pin::deref should be safe.

Cc @rust-lang/opsem