Tracking Issue for RFC 3467: UnsafePinned

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.
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
- This was decided via champion decision and meeting consensus in a shorthanded meeting; this item will need to receive attention in the stabilization report.
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)
Do we need all these get methods?
UnsafePinned should provide the same guarantee layouts as UnsafeCell #156163
What about variance?

Implementation history

TODO.

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.

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

Auto merge of rust-lang#129313 - RalfJung:coroutine-niches, r=compile…

Auto merge of #129313 - RalfJung:coroutine-niches, r=compiler-errors

Unrolled build for #145593

Rollup merge of rust-lang#145593 - RalfJung:unsafepinned-raw_get, r=M…

Do we want to bikeshed the name further before stabilization?

If get_mut_unchecked and get_mut_pinned are someday stabilized, yes, they should absolutely be renamed to get_unchecked_mut and get_pinned_mut for consistency.

Another case of UB caused by unintended uniqueness in futures: rust-lang/miri#4809.

It's really high time that we fix the async lowering to use UnsafePinned to finally properly tackle this ancient I-unsound issue.

Rollup merge of rust-lang#151365 - RalfJung:unsafe-unpin-opsem, r=Box…

Unrolled build for #151365

Rollup merge of #151365 - RalfJung:unsafe-unpin-opsem, r=BoxyUwU

Rollup merge of rust-lang#152646 - zachs18:unsafeunpin-marker-impls-p…

Unrolled build for #152646

Hi, question about what seems to be an omission in the documentation: should UnsafePinned make the same layout guarantees as UnsafeCell? 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 T within an UnsafePinned<T>, using e.g. Crubit's ctor crate, 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 UnsafePinned also wrap UnsafeCell changes the variance of UnsafePinned. In 1.87/1.88 UnsafePinned is covariant, while 1.89+ it becomes invariant. This makes it much more limiting than PhantomPinned as 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 CovariantUnsafeCell then UnsafePinned should move to use that instead.

Navigation Menu

Repository navigation

Tracking Issue for RFC 3467: UnsafePinned #125735

About tracking issues

Steps

Unresolved Questions

Related

Implementation history

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for RFC 3467: UnsafePinned #125735

Description

About tracking issues

Steps

Unresolved Questions

Related

Implementation history

Activity

RalfJung commented on Aug 2, 2024

RalfJung commented on Aug 20, 2024

26 remaining items

jdahlstrom commented on Oct 25, 2025

RalfJung commented on Jan 19, 2026

jacobsa commented on May 4, 2026

RalfJung commented on May 4, 2026

nbdd0121 commented on Jul 21, 2026

RalfJung commented on Jul 21, 2026

nbdd0121 commented on Jul 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions