Repository navigation
Tracking Issue for RFC 3467: UnsafePinned #125735
Description
Activity
- added
on May 29, 2024 Turns out the existing hack that attempts to make self-referential async lowering sound is incomplete, and we most likely need
UnsafePinnedto make it actually sound.In the RFC we had the question whether
UnsafePinnedshould also act like anUnsafeCell. I am now fairly sure that the answer is "yes, it must". The reason is this: due toPin::derefbeing 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 noUnsafeCell, 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 thatPin::derefshould be safe.Cc @rust-lang/opsem
Reacted by Ben Kimock, Martin Habovštiak, Onestacked, Crystal Durham, Guillaume Raffin, Oleksandr Babak and Taylor Cramer- added 4 commits that reference this issue
on Sep 4, 2024 - added a commit that references this issue
on Sep 10, 2024 - added a commit that references this issue
on Sep 25, 2024 26 remaining items
- added a commit that references this issue
on Aug 21, 2025 Do we want to bikeshed the name further before stabilization?
If
get_mut_uncheckedandget_mut_pinnedare someday stabilized, yes, they should absolutely be renamed toget_unchecked_mutandget_pinned_mutfor consistency.Another case of UB caused by unintended uniqueness in futures: rust-lang/miri#4809.
It's really high time that we fix the
asynclowering to useUnsafePinnedto finally properly tackle this ancient I-unsound issue.Reacted by waffle, Scott Lamb, Raphaël Thériault and Niket Naidu- added a commit that references this issue
on Feb 15, 2026 - added a commit that references this issue
on Feb 15, 2026 Hi, question about what seems to be an omission in the documentation: should
UnsafePinnedmake the same layout guarantees asUnsafeCell? I assume that's more or less intended, but it would be good to be explicit (and in any case I'd still be happy with an answer here).For the record: the reason I care is that I'm pretty sure I need this guarantee in order to be able to do in-place initialization of the
Twithin anUnsafePinned<T>, using e.g. Crubit'sctorcrate, at least in order for it to approach being ergonomic.Yeah it would make sense to give it the same layout guarantees.
The change that make
UnsafePinnedalso wrapUnsafeCellchanges the variance ofUnsafePinned. In 1.87/1.88UnsafePinnedis covariant, while 1.89+ it becomes invariant. This makes it much more limiting thanPhantomPinnedas that doesn't change the variance.For code that just needs pinning for self-reference and not for mutation, this is very limiting.
Oh yeah I didn't think about variance at all.
It would seem a bit odd if UnsafePinned becomes the way to have covariant interior mutability...
Well, I suppose if we have
CovariantUnsafeCellthenUnsafePinnedshould move to use that instead.
This is a tracking issue for RFC 3467:
UnsafePinned.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
UnsafePinnedimplementation [Part 1: Libs] #137043UnsafePinnedimplementation [Part 2: Lowering] #139896Unresolved Questions
&UnsafePinnedpermit mutation or not? Also see Decide what to do aboutUnsafePinnedand safePin::as_ref#137750Send,Sync,Copy,Cloneshould this type implement under which conditions? Also see this.Freezefirst? And what about the equivalent trait for&mutaliasing (UnpinUnsafein the RFC)?getmethods?Related
Implementation history
TODO.