1//! Types that pin data to a location in memory.
2//!
3//! It is sometimes useful to be able to rely upon a certain value not being able to *move*,
4//! in the sense that its address in memory cannot change. This is useful especially when there
5//! are one or more [*pointers*][pointer] pointing at that value. The ability to rely on this
6//! guarantee that the value a [pointer] is pointing at (its **pointee**) will
7//!
8//! 1. Not be *moved* out of its memory location
9//! 2. More generally, remain *valid* at that same memory location
10//!
11//! is called "pinning." We would say that a value which satisfies these guarantees has been
12//! "pinned," in that it has been permanently (until the end of its lifespan) attached to its
13//! location in memory, as though pinned to a pinboard. Pinning a value is an incredibly useful
14//! building block for [`unsafe`] code to be able to reason about whether a raw pointer to the
15//! pinned value is still valid. [As we'll see later][drop-guarantee], this is necessarily from the
16//! time the value is first pinned until the end of its lifespan. This concept of "pinning" is
17//! necessary to implement safe interfaces on top of things like self-referential types and
18//! intrusive data structures which cannot currently be modeled in fully safe Rust using only
19//! borrow-checked [references][reference].
20//!
21//! "Pinning" allows us to put a *value* which exists at some location in memory into a state where
22//! safe code cannot *move* that value to a different location in memory or otherwise invalidate it
23//! at its current location (unless it implements [`Unpin`], which we will
24//! [talk about below][self#unpin]). Anything that wants to interact with the pinned value in a way
25//! that has the potential to violate these guarantees must promise that it will not actually
26//! violate them, using the [`unsafe`] keyword to mark that such a promise is upheld by the user
27//! and not the compiler. In this way, we can allow other [`unsafe`] code to rely on any pointers
28//! that point to the pinned value to be valid to dereference while it is pinned.
29//!
30//! Note that as long as you don't use [`unsafe`], it's impossible to create or misuse a pinned
31//! value in a way that is unsound. See the documentation of [`Pin<Ptr>`] for more
32//! information on the practicalities of how to pin a value and how to use that pinned value from a
33//! user's perspective without using [`unsafe`].
34//!
35//! The rest of this documentation is intended to be the source of truth for users of [`Pin<Ptr>`]
36//! that are implementing the [`unsafe`] pieces of an interface that relies on pinning for validity;
37//! users of [`Pin<Ptr>`] in safe code do not need to read it in detail.
38//!
39//! There are several sections to this documentation:
40//!
41//! * [What is "*moving*"?][what-is-moving]
42//! * [What is "pinning"?][what-is-pinning]
43//! * [Address sensitivity, AKA "when do we need pinning?"][address-sensitive-values]
44//! * [Examples of types with address-sensitive states][address-sensitive-examples]
45//! * [Self-referential struct][self-ref]
46//! * [Intrusive, doubly-linked list][linked-list]
47//! * [Subtle details and the `Drop` guarantee][subtle-details]
48//!
49//! # What is "*moving*"?
50//! [what-is-moving]: self#what-is-moving
51//!
52//! When we say a value is *moved*, we mean that the compiler copies, byte-for-byte, the
53//! value from one location to another. In a purely mechanical sense, this is identical to
54//! [`Copy`]ing a value from one place in memory to another. In Rust, "move" carries with it the
55//! semantics of ownership transfer from one variable to another, which is the key difference
56//! between a [`Copy`] and a move. For the purposes of this module's documentation, however, when
57//! we write *move* in italics, we mean *specifically* that the value has *moved* in the mechanical
58//! sense of being located at a new place in memory.
59//!
60//! All values in Rust are trivially *moveable*. This means that the address at which a value is
61//! located is not necessarily stable in between borrows. The compiler is allowed to *move* a value
62//! to a new address without running any code to notify that value that its address
63//! has changed. Although the compiler will not insert memory *moves* where no semantic move has
64//! occurred, there are many places where a value *may* be moved. For example, when doing
65//! assignment or passing a value into a function.
66//!
67//! ```
68//! #[derive(Default)]
69//! struct AddrTracker(Option<usize>);
70//!
71//! impl AddrTracker {
72//! // If we haven't checked the addr of self yet, store the current
73//! // address. If we have, confirm that the current address is the same
74//! // as it was last time, or else panic.
75//! fn check_for_move(&mut self) {
76//! let current_addr = self as *mut Self as usize;
77//! match self.0 {
78//! None => self.0 = Some(current_addr),
79//! Some(prev_addr) => assert_eq!(prev_addr, current_addr),
80//! }
81//! }
82//! }
83//!
84//! // Create a tracker and store the initial address
85//! let mut tracker = AddrTracker::default();
86//! tracker.check_for_move();
87//!
88//! // Here we shadow the variable. This carries a semantic move, and may therefore also
89//! // come with a mechanical memory *move*
90//! let mut tracker = tracker;
91//!
92//! // May panic!
93//! // tracker.check_for_move();
94//! ```
95//!
96//! In this sense, Rust does not guarantee that `check_for_move()` will never panic, because the
97//! compiler is permitted to *move* `tracker` in many situations.
98//!
99//! Common smart-pointer types such as [`Box<T>`] and [`&mut T`] also allow *moving* the underlying
100//! *value* they point at: you can move out of a [`Box<T>`], or you can use [`mem::replace`] to
101//! move a `T` out of a [`&mut T`]. Therefore, putting a value (such as `tracker` above) behind a
102//! pointer isn't enough on its own to ensure that its address does not change.
103//!
104//! # What is "pinning"?
105//! [what-is-pinning]: self#what-is-pinning
106//!
107//! We say that a value has been *pinned* when it has been put into a state where it is guaranteed
108//! to remain *located at the same place in memory* from the time it is pinned until its
109//! [`drop`] is called.
110//!
111//! ## Address-sensitive values, AKA "when we need pinning"
112//! [address-sensitive-values]: self#address-sensitive-values-aka-when-we-need-pinning
113//!
114//! Most values in Rust are entirely okay with being *moved* around at-will.
115//! Types for which it is *always* the case that *any* value of that type can be
116//! *moved* at-will should implement [`Unpin`], which we will discuss more [below][self#unpin].
117//!
118//! [`Pin`] is specifically targeted at allowing the implementation of *safe interfaces* around
119//! types which have some state during which they become "address-sensitive." A value in such an
120//! "address-sensitive" state is *not* okay with being *moved* around at-will. Such a value must
121//! stay *un-moved* and valid during the address-sensitive portion of its lifespan because some
122//! interface is relying on those invariants to be true in order for its implementation to be sound.
123//!
124//! As a motivating example of a type which may become address-sensitive, consider a type which
125//! contains a pointer to another piece of its own data, *i.e.* a "self-referential" type. In order
126//! for such a type to be implemented soundly, the pointer which points into `self`'s data must be
127//! proven valid whenever it is accessed. But if that value is *moved*, the pointer will still
128//! point to the old address where the value was located and not into the new location of `self`,
129//! thus becoming invalid. A key example of such self-referential types are the state machines
130//! generated by the compiler to implement [`Future`] for `async fn`s.
131//!
132//! Such types that have an *address-sensitive* state usually follow a lifecycle
133//! that looks something like so:
134//!
135//! 1. A value is created which can be freely moved around.
136//! * e.g. calling an async function which returns a state machine implementing [`Future`]
137//! 2. An operation causes the value to depend on its own address not changing
138//! * e.g. calling [`poll`] for the first time on the produced [`Future`]
139//! 3. Further pieces of the safe interface of the type use internal [`unsafe`] operations which
140//! assume that the address of the value is stable
141//! * e.g. subsequent calls to [`poll`]
142//! 4. Before the value is invalidated (e.g. deallocated), it is *dropped*, giving it a chance to
143//! notify anything with pointers to itself that those pointers will be invalidated
144//! * e.g. [`drop`]ping the [`Future`] [^pin-drop-future]
145//!
146//! There are two possible ways to ensure the invariants required for 2. and 3. above (which
147//! apply to any address-sensitive type, not just self-referrential types) do not get broken.
148//!
149//! 1. Have the value detect when it is moved and update all the pointers that point to itself.
150//! 2. Guarantee that the address of the value does not change (and that memory is not re-used
151//! for anything else) during the time that the pointers to it are expected to be valid to
152//! dereference.
153//!
154//! Since, as we discussed, Rust can move values without notifying them that they have moved, the
155//! first option is ruled out.
156//!
157//! In order to implement the second option, we must in some way enforce its key invariant,
158//! *i.e.* prevent the value from being *moved* or otherwise invalidated (you may notice this
159//! sounds an awful lot like the definition of *pinning* a value). There a few ways one might be
160//! able to enforce this invariant in Rust:
161//!
162//! 1. Offer a wholly `unsafe` API to interact with the object, thus requiring every caller to
163//! uphold the invariant themselves
164//! 2. Store the value that must not be moved behind a carefully managed pointer internal to
165//! the object
166//! 3. Leverage the type system to encode and enforce this invariant by presenting a restricted
167//! API surface to interact with *any* object that requires these invariants
168//!
169//! The first option is quite obviously undesirable, as the [`unsafe`]ty of the interface will
170//! become viral throughout all code that interacts with the object.
171//!
172//! The second option is a viable solution to the problem for some use cases, in particular
173//! for self-referrential types. Under this model, any type that has an address sensitive state
174//! would ultimately store its data in something like a [`Box<T>`], carefully manage internal
175//! access to that data to ensure no *moves* or other invalidation occurs, and finally
176//! provide a safe interface on top.
177//!
178//! There are a couple of linked disadvantages to using this model. The most significant is that
179//! each individual object must assume it is *on its own* to ensure
180//! that its data does not become *moved* or otherwise invalidated. Since there is no shared
181//! contract between values of different types, an object cannot assume that others interacting
182//! with it will properly respect the invariants around interacting with its data and must
183//! therefore protect it from everyone. Because of this, *composition* of address-sensitive types
184//! requires at least a level of pointer indirection each time a new object is added to the mix
185//! (and, practically, a heap allocation).
186//!
187//! Although there were other reason as well, this issue of expensive composition is the key thing
188//! that drove Rust towards adopting a different model. It is particularly a problem
189//! when one considers, for exapmle, the implications of composing together the [`Future`]s which
190//! will eventaully make up an asynchronous task (including address-sensitive `async fn` state
191//! machines). It is plausible that there could be many layers of [`Future`]s composed together,
192//! including multiple layers of `async fn`s handling different parts of a task. It was deemed
193//! unacceptable to force indirection and allocation for each layer of composition in this case.
194//!
195//! [`Pin<Ptr>`] is an implementation of the third option. It allows us to solve the issues
196//! discussed with the second option by building a *shared contractual language* around the
197//! guarantees of "pinning" data.
198//!
199//! [^pin-drop-future]: Futures themselves do not ever need to notify other bits of code that
200//! they are being dropped, however data structures like stack-based intrusive linked lists do.
201//!
202//! ## Using [`Pin<Ptr>`] to pin values
203//!
204//! In order to pin a value, we wrap a *pointer to that value* (of some type `Ptr`) in a
205//! [`Pin<Ptr>`]. [`Pin<Ptr>`] can wrap any pointer type, forming a promise that the **pointee**
206//! will not be *moved* or [otherwise invalidated][subtle-details].
207//!
208//! We call such a [`Pin`]-wrapped pointer a **pinning pointer,** (or pinning reference, or pinning
209//! `Box`, etc.) because its existence is the thing that is conceptually pinning the underlying
210//! pointee in place: it is the metaphorical "pin" securing the data in place on the pinboard
211//! (in memory).
212//!
213//! Notice that the thing wrapped by [`Pin`] is not the value which we want to pin itself, but
214//! rather a pointer to that value! A [`Pin<Ptr>`] does not pin the `Ptr`; instead, it pins the
215//! pointer's ***pointee** value*.
216//!
217//! ### Pinning as a library contract
218//!
219//! Pinning does not require nor make use of any compiler "magic"[^noalias], only a specific
220//! contract between the [`unsafe`] parts of a library API and its users.
221//!
222//! It is important to stress this point as a user of the [`unsafe`] parts of the [`Pin`] API.
223//! Practically, this means that performing the mechanics of "pinning" a value by creating a
224//! [`Pin<Ptr>`] to it *does not* actually change the way the compiler behaves towards the
225//! inner value! It is possible to use incorrect [`unsafe`] code to create a [`Pin<Ptr>`] to a
226//! value which does not actually satisfy the invariants that a pinned value must satisfy, and in
227//! this way lead to undefined behavior even in (from that point) fully safe code. Similarly, using
228//! [`unsafe`], one may get access to a bare [`&mut T`] from a [`Pin<Ptr>`] and
229//! use that to invalidly *move* the pinned value out. It is the job of the user of the
230//! [`unsafe`] parts of the [`Pin`] API to ensure these invariants are not violated.
231//!
232//! This differs from e.g. [`UnsafeCell`] which changes the semantics of a program's compiled
233//! output. A [`Pin<Ptr>`] is a handle to a value which we have promised we will not move out of,
234//! but Rust still considers all values themselves to be fundamentally moveable through, *e.g.*
235//! assignment or [`mem::replace`].
236//!
237//! [^noalias]: There is a bit of nuance here that is still being decided about what the aliasing
238//! semantics of `Pin<&mut T>` should be, but this is true as of today.
239//!
240//! ### How [`Pin`] prevents misuse in safe code
241//!
242//! In order to accomplish the goal of pinning the pointee value, [`Pin<Ptr>`] restricts access to
243//! the wrapped `Ptr` type in safe code. Specifically, [`Pin`] disallows the ability to access
244//! the wrapped pointer in ways that would allow the user to *move* the underlying pointee value or
245//! otherwise re-use that memory for something else without using [`unsafe`]. For example, a
246//! [`Pin<&mut T>`] makes it impossible to obtain the wrapped <code>[&mut] T</code> safely because
247//! through that <code>[&mut] T</code> it would be possible to *move* the underlying value out of
248//! the pointer with [`mem::replace`], etc.
249//!
250//! As discussed above, this promise must be upheld manually by [`unsafe`] code which interacts
251//! with the [`Pin<Ptr>`] so that other [`unsafe`] code can rely on the pointee value being
252//! *un-moved* and valid. Interfaces that operate on values which are in an address-sensitive state
253//! accept an argument like <code>[Pin]<[&mut] T></code> or <code>[Pin]<[Box]\<T>></code> to
254//! indicate this contract to the caller.
255//!
256//! [As discussed below][drop-guarantee], opting in to using pinning guarantees in the interface
257//! of an address-sensitive type has consequences for the implementation of some safe traits on
258//! that type as well.
259//!
260//! ## Interaction between [`Deref`] and [`Pin<Ptr>`]
261//!
262//! Since [`Pin<Ptr>`] can wrap any pointer type, it uses [`Deref`] and [`DerefMut`] in
263//! order to identify the type of the pinned pointee data and provide (restricted) access to it.
264//!
265//! A [`Pin<Ptr>`] where [`Ptr: Deref`][Deref] is a "`Ptr`-style pinning pointer" to a pinned
266//! [`Ptr::Target`][Target] – so, a <code>[Pin]<[Box]\<T>></code> is an owned, pinning pointer to a
267//! pinned `T`, and a <code>[Pin]<[Rc]\<T>></code> is a reference-counted, pinning pointer to a
268//! pinned `T`.
269//!
270//! [`Pin<Ptr>`] also uses the [`<Ptr as Deref>::Target`][Target] type information to modify the
271//! interface it is allowed to provide for interacting with that data (for example, when a
272//! pinning pointer points at pinned data which implements [`Unpin`], as
273//! [discussed below][self#unpin]).
274//!
275//! [`Pin<Ptr>`] requires that implementations of [`Deref`] and [`DerefMut`] on `Ptr` return a
276//! pointer to the pinned data directly and do not *move* out of the `self` parameter during their
277//! implementation of [`DerefMut::deref_mut`]. It is unsound for [`unsafe`] code to wrap pointer
278//! types with such "malicious" implementations of [`Deref`]; see [`Pin<Ptr>::new_unchecked`] for
279//! details.
280//!
281//! ## Fixing `AddrTracker`
282//!
283//! The guarantee of a stable address is necessary to make our `AddrTracker` example work. When
284//! `check_for_move` sees a <code>[Pin]<&mut AddrTracker></code>, it can safely assume that value
285//! will exist at that same address until said value goes out of scope, and thus multiple calls
286//! to it *cannot* panic.
287//!
288//! ```
289//! use std::marker::PhantomPinned;
290//! use std::pin::Pin;
291//! use std::pin::pin;
292//!
293//! #[derive(Default)]
294//! struct AddrTracker {
295//! prev_addr: Option<usize>,
296//! // remove auto-implemented `Unpin` bound to mark this type as having some
297//! // address-sensitive state. This is essential for our expected pinning
298//! // guarantees to work, and is discussed more below.
299//! _pin: PhantomPinned,
300//! }
301//!
302//! impl AddrTracker {
303//! fn check_for_move(self: Pin<&mut Self>) {
304//! let current_addr = &*self as *const Self as usize;
305//! match self.prev_addr {
306//! None => {
307//! // SAFETY: we do not move out of self
308//! let self_data_mut = unsafe { self.get_unchecked_mut() };
309//! self_data_mut.prev_addr = Some(current_addr);
310//! },
311//! Some(prev_addr) => assert_eq!(prev_addr, current_addr),
312//! }
313//! }
314//! }
315//!
316//! // 1. Create the value, not yet in an address-sensitive state
317//! let tracker = AddrTracker::default();
318//!
319//! // 2. Pin the value by putting it behind a pinning pointer, thus putting
320//! // it into an address-sensitive state
321//! let mut ptr_to_pinned_tracker: Pin<&mut AddrTracker> = pin!(tracker);
322//! ptr_to_pinned_tracker.as_mut().check_for_move();
323//!
324//! // Trying to access `tracker` or pass `ptr_to_pinned_tracker` to anything that requires
325//! // mutable access to a non-pinned version of it will no longer compile
326//!
327//! // 3. We can now assume that the tracker value will never be moved, thus
328//! // this will never panic!
329//! ptr_to_pinned_tracker.as_mut().check_for_move();
330//! ```
331//!
332//! Note that this invariant is enforced by simply making it impossible to call code that would
333//! perform a move on the pinned value. This is the case since the only way to access that pinned
334//! value is through the pinning <code>[Pin]<[&mut] T>></code>, which in turn restricts our access.
335//!
336//! ## [`Unpin`]
337//!
338//! The vast majority of Rust types have no address-sensitive states. These types
339//! implement the [`Unpin`] auto-trait, which cancels the restrictive effects of
340//! [`Pin`] when the *pointee* type `T` is [`Unpin`]. When [`T: Unpin`][Unpin],
341//! <code>[Pin]<[Box]\<T>></code> functions identically to a non-pinning [`Box<T>`]; similarly,
342//! <code>[Pin]<[&mut] T></code> would impose no additional restrictions above a regular
343//! [`&mut T`].
344//!
345//! The idea of this trait is to alleviate the reduced ergonomics of APIs that require the use
346//! of [`Pin`] for soundness for some types, but which also want to be used by other types that
347//! don't care about pinning. The prime example of such an API is [`Future::poll`]. There are many
348//! [`Future`] types that don't care about pinning. These futures can implement [`Unpin`] and
349//! therefore get around the pinning related restrictions in the API, while still allowing the
350//! subset of [`Future`]s which *do* require pinning to be implemented soundly.
351//!
352//! Note that the interaction between a [`Pin<Ptr>`] and [`Unpin`] is through the type of the
353//! **pointee** value, [`<Ptr as Deref>::Target`][Target]. Whether the `Ptr` type itself
354//! implements [`Unpin`] does not affect the behavior of a [`Pin<Ptr>`]. For example, whether or not
355//! [`Box`] is [`Unpin`] has no effect on the behavior of <code>[Pin]<[Box]\<T>></code>, because
356//! `T` is the type of the pointee value, not [`Box`]. So, whether `T` implements [`Unpin`] is
357//! the thing that will affect the behavior of the <code>[Pin]<[Box]\<T>></code>.
358//!
359//! Builtin types that are [`Unpin`] include all of the primitive types, like [`bool`], [`i32`],
360//! and [`f32`], references (<code>[&]T</code> and <code>[&mut] T</code>), etc., as well as many
361//! core and standard library types like [`Box<T>`], [`String`], and more.
362//! These types are marked [`Unpin`] because they do not have an ddress-sensitive state like the
363//! ones we discussed above. If they did have such a state, those parts of their interface would be
364//! unsound without being expressed through pinning, and they would then need to not
365//! implement [`Unpin`].
366//!
367//! The compiler is free to take the conservative stance of marking types as [`Unpin`] so long as
368//! all of the types that compose its fields are also [`Unpin`]. This is because if a type
369//! implements [`Unpin`], then it is unsound for that type's implementation to rely on
370//! pinning-related guarantees for soundness, *even* when viewed through a "pinning" pointer! It is
371//! the responsibility of the implementor of a type that relies upon pinning for soundness to
372//! ensure that type is *not* marked as [`Unpin`] by adding [`PhantomPinned`] field. This is
373//! exactly what we did with our `AddrTracker` example above. Without doing this, you *must not*
374//! rely on pinning-related guarantees to apply to your type!
375//!
376//! If need to truly pin a value of a foreign or built-in type that implements [`Unpin`], you'll
377//! need to create your own wrapper type around the [`Unpin`] type you want to pin and then
378//! opts-out of [`Unpin`] using [`PhantomPinned`].
379//!
380//! Exposing access to the inner field which you want to remain pinned must then be carefully
381//! considered as well! Remember, exposing a method that gives access to a
382//! <code>[Pin]<[&mut] InnerT>></code> where `InnerT: [Unpin]` would allow safe code to trivially
383//! move the inner value out of that pinning pointer, which is precisely what you're seeking to
384//! prevent! Exposing a field of a pinned value through a pinning pointer is called "projecting"
385//! a pin, and the more general case of deciding in which cases a pin should be able to be
386//! projected or not is called "structural pinning." We will go into more detail about this
387//! [below][structural-pinning].
388//!
389//! # Examples of address-sensitive types
390//! [address-sensitive-examples]: #examples-of-address-sensitive-types
391//!
392//! ## A self-referential struct
393//! [self-ref]: #a-self-referential-struct
394//! [`Unmovable`]: #a-self-referential-struct
395//!
396//! Self-referential structs are the simplest kind of address-sensitive type.
397//!
398//! It is often useful for a struct to hold a pointer back into itself, which
399//! allows the program to efficiently track subsections of the struct.
400//! Below, the `slice` field is a pointer into the `data` field, which
401//! we could imagine being used to track a sliding window of `data` in parser
402//! code.
403//!
404//! As mentioned before, this pattern is also used extensively by compiler-generated
405//! [`Future`]s.
406//!
407//! ```rust
408//! use std::pin::Pin;
409//! use std::marker::PhantomPinned;
410//! use std::ptr::NonNull;
411//!
412//! /// This is a self-referential struct because `self.slice` points into `self.data`.
413//! struct Unmovable {
414//! /// Backing buffer.
415//! data: [u8; 64],
416//! /// Points at `self.data` which we know is itself non-null. Raw pointer because we can't do
417//! /// this with a normal reference.
418//! slice: NonNull<[u8]>,
419//! /// Suppress `Unpin` so that this cannot be moved out of a `Pin` once constructed.
420//! _pin: PhantomPinned,
421//! }
422//!
423//! impl Unmovable {
424//! /// Create a new `Unmovable`.
425//! ///
426//! /// To ensure the data doesn't move we place it on the heap behind a pinning Box.
427//! /// Note that the data is pinned, but the `Pin<Box<Self>>` which is pinning it can
428//! /// itself still be moved. This is important because it means we can return the pinning
429//! /// pointer from the function, which is itself a kind of move!
430//! fn new() -> Pin<Box<Self>> {
431//! let res = Unmovable {
432//! data: [0; 64],
433//! // We only create the pointer once the data is in place
434//! // otherwise it will have already moved before we even started.
435//! slice: NonNull::from(&[]),
436//! _pin: PhantomPinned,
437//! };
438//! // First we put the data in a box, which will be its final resting place
439//! let mut boxed = Box::new(res);
440//!
441//! // Then we make the slice field point to the proper part of that boxed data.
442//! // From now on we need to make sure we don't move the boxed data.
443//! boxed.slice = NonNull::from(&boxed.data);
444//!
445//! // To do that, we pin the data in place by pointing to it with a pinning
446//! // (`Pin`-wrapped) pointer.
447//! //
448//! // `Box::into_pin` makes existing `Box` pin the data in-place without moving it,
449//! // so we can safely do this now *after* inserting the slice pointer above, but we have
450//! // to take care that we haven't performed any other semantic moves of `res` in between.
451//! let pin = Box::into_pin(boxed);
452//!
453//! // Now we can return the pinned (through a pinning Box) data
454//! pin
455//! }
456//! }
457//!
458//! let unmovable: Pin<Box<Unmovable>> = Unmovable::new();
459//!
460//! // The inner pointee `Unmovable` struct will now never be allowed to move.
461//! // Meanwhile, we are free to move the pointer around.
462//! # #[allow(unused_mut)]
463//! let mut still_unmoved = unmovable;
464//! assert_eq!(still_unmoved.slice, NonNull::from(&still_unmoved.data));
465//!
466//! // We cannot mutably dereference a `Pin<Ptr>` unless the pointee is `Unpin` or we use unsafe.
467//! // Since our type doesn't implement `Unpin`, this will fail to compile.
468//! // let mut new_unmoved = Unmovable::new();
469//! // std::mem::swap(&mut *still_unmoved, &mut *new_unmoved);
470//! ```
471//!
472//! ## An intrusive, doubly-linked list
473//! [linked-list]: #an-intrusive-doubly-linked-list
474//!
475//! In an intrusive doubly-linked list, the collection itself does not own the memory in which
476//! each of its elements is stored. Instead, each client is free to allocate space for elements it
477//! adds to the list in whichever manner it likes, including on the stack! Elements can live on a
478//! stack frame that lives shorter than the collection does provided the elements that live in a
479//! given stack frame are removed from the list before going out of scope.
480//!
481//! To make such an intrusive data structure work, every element stores pointers to its predecessor
482//! and successor within its own data, rather than having the list structure itself managing those
483//! pointers. It is in this sense that the structure is "intrusive": the details of how an
484//! element is stored within the larger structure "intrudes" on the implementation of the element
485//! type itself!
486//!
487//! The full implementation details of such a data structure are outside the scope of this
488//! documentation, but we will discuss how [`Pin`] can help to do so.
489//!
490//! Using such an intrusive pattern, elements may only be added when they are pinned. If we think
491//! about the consequences of adding non-pinned values to such a list, this becomes clear:
492//!
493//! *Moving* or otherwise invalidating an element's data would invalidate the pointers back to it
494//! which are stored in the elements ahead and behind it. Thus, in order to soundly dereference
495//! the pointers stored to the next and previous elements, we must satisfy the guarantee that
496//! nothing has invalidated those pointers (which point to data that we do not own).
497//!
498//! Moreover, the [`Drop`][Drop] implementation of each element must in some way notify its
499//! predecessor and successor elements that it should be removed from the list before it is fully
500//! destroyed, otherwise the pointers back to it would again become invalidated.
501//!
502//! Crucially, this means we have to be able to rely on [`drop`] always being called before an
503//! element is invalidated. If an element could be deallocated or otherwise invalidated without
504//! calling [`drop`], the pointers to it stored in its neighboring elements would
505//! become invalid, which would break the data structure.
506//!
507//! Therefore, pinning data also comes with [the "`Drop` guarantee"][drop-guarantee].
508//!
509//! # Subtle details and the `Drop` guarantee
510//! [subtle-details]: self#subtle-details-and-the-drop-guarantee
511//! [drop-guarantee]: self#subtle-details-and-the-drop-guarantee
512//!
513//! The purpose of pinning is not *just* to prevent a value from being *moved*, but more
514//! generally to be able to rely on the pinned value *remaining valid **at a specific place*** in
515//! memory.
516//!
517//! To do so, pinning a value adds an *additional* invariant that must be upheld in order for use
518//! of the pinned data to be valid, on top of the ones that must be upheld for a non-pinned value
519//! of the same type to be valid:
520//!
521//! From the moment a value is pinned by constructing a [`Pin`]ning pointer to it, that value
522//! must *remain, **valid***, at that same address in memory, *until its [`drop`] handler is
523//! called.*
524//!
525//! There is some subtlety to this which we have not yet talked about in detail. The invariant
526//! described above means that, yes,
527//!
528//! 1. The value must not be moved out of its location in memory
529//!
530//! but it also implies that,
531//!
532//! 2. The memory location that stores the value must not get invalidated or otherwise repurposed
533//! during the lifespan of the pinned value until its [`drop`] returns or panics
534//!
535//! This point is subtle but required for intrusive data structures to be implemented soundly.
536//!
537//! ## `Drop` guarantee
538//!
539//! There needs to be a way for a pinned value to notify any code that is relying on its pinned
540//! status that it is about to be destroyed. In this way, the dependent code can remove the
541//! pinned value's address from its data structures or otherwise change its behavior with the
542//! knowledge that it can no longer rely on that value existing at the location it was pinned to.
543//!
544//! Thus, in any situation where we may want to overwrite a pinned value, that value's [`drop`] must
545//! be called beforehand (unless the pinned value implements [`Unpin`], in which case we can ignore
546//! all of [`Pin`]'s guarantees, as usual).
547//!
548//! The most common storage-reuse situations occur when a value on the stack is destroyed as part
549//! of a function return and when heap storage is freed. In both cases, [`drop`] gets run for us
550//! by Rust when using standard safe code. However, for manual heap allocations or otherwise
551//! custom-allocated storage, [`unsafe`] code must make sure to call [`ptr::drop_in_place`] before
552//! deallocating and re-using said storage.
553//!
554//! In addition, storage "re-use"/invalidation can happen even if no storage is (de-)allocated.
555//! For example, if we had an [`Option`] which contained a `Some(v)` where `v` is pinned, then `v`
556//! would be invalidated by setting that option to `None`.
557//!
558//! Similarly, if a [`Vec`] was used to store pinned values and [`Vec::set_len`] was used to
559//! manually "kill" some elements of a vector, all of the items "killed" would become invalidated,
560//! which would be *undefined behavior* if those items were pinned.
561//!
562//! Both of these cases are somewhat contrived, but it is crucial to remember that [`Pin`]ned data
563//! *must* be [`drop`]ped before it is invalidated; not just to prevent memory leaks, but as a
564//! matter of soundness. As a corollary, the following code can *never* be made safe:
565//!
566//! ```rust
567//! # use std::mem::ManuallyDrop;
568//! # use std::pin::Pin;
569//! # struct Type;
570//! // Pin something inside a `ManuallyDrop`. This is fine on its own.
571//! let mut pin: Pin<Box<ManuallyDrop<Type>>> = Box::pin(ManuallyDrop::new(Type));
572//!
573//! // However, creating a pinning mutable reference to the type *inside*
574//! // the `ManuallyDrop` is not!
575//! let inner: Pin<&mut Type> = unsafe {
576//! Pin::map_unchecked_mut(pin.as_mut(), |x| &mut **x)
577//! };
578//! ```
579//!
580//! Because [`mem::ManuallyDrop`] inhibits the destructor of `Type`, it won't get run when the
581//! <code>[Box]<[ManuallyDrop]\<Type>></code> is dropped, thus violating the drop guarantee of the
582//! <code>[Pin]<[&mut] Type>></code>.
583//!
584//! Of course, *leaking* memory in such a way that its underlying storage will never get invalidated
585//! or re-used is still fine: [`mem::forget`]ing a [`Box<T>`] prevents its storage from ever getting
586//! re-used, so the [`drop`] guarantee is still satisfied.
587//!
588//! # Implementing an address-sensitive type.
589//!
590//! This section goes into detail on important considerations for implementing your own
591//! address-sensitive types, which are different from merely using [`Pin<Ptr>`] in a generic
592//! way.
593//!
594//! ## Implementing [`Drop`] for types with address-sensitive states
595//! [drop-impl]: self#implementing-drop-for-types-with-address-sensitive-states
596//!
597//! The [`drop`] function takes [`&mut self`], but this is called *even if that `self` has been
598//! pinned*! Implementing [`Drop`] for a type with address-sensitive states, because if `self` was
599//! indeed in an address-sensitive state before [`drop`] was called, it is as if the compiler
600//! automatically called [`Pin::get_unchecked_mut`].
601//!
602//! This can never cause a problem in purely safe code because creating a pinning pointer to
603//! a type which has an address-sensitive (thus does not implement `Unpin`) requires `unsafe`,
604//! but it is important to note that choosing to take advantage of pinning-related guarantees
605//! to justify validity in the implementation of your type has consequences for that type's
606//! [`Drop`][Drop] implementation as well: if an element of your type could have been pinned,
607//! you must treat [`Drop`][Drop] as implicitly taking <code>self: [Pin]<[&mut] Self></code>.
608//!
609//! You should implement [`Drop`] as follows:
610//!
611//! ```rust,no_run
612//! # use std::pin::Pin;
613//! # struct Type;
614//! impl Drop for Type {
615//! fn drop(&mut self) {
616//! // `new_unchecked` is okay because we know this value is never used
617//! // again after being dropped.
618//! inner_drop(unsafe { Pin::new_unchecked(self)});
619//! fn inner_drop(this: Pin<&mut Type>) {
620//! // Actual drop code goes here.
621//! }
622//! }
623//! }
624//! ```
625//!
626//! The function `inner_drop` has the signature that [`drop`] *should* have in this situation.
627//! This makes sure that you do not accidentally use `self`/`this` in a way that is in conflict
628//! with pinning's invariants.
629//!
630//! Moreover, if your type is [`#[repr(packed)]`][packed], the compiler will automatically
631//! move fields around to be able to drop them. It might even do
632//! that for fields that happen to be sufficiently aligned. As a consequence, you cannot use
633//! pinning with a [`#[repr(packed)]`][packed] type.
634//!
635//! ### Implementing [`Drop`] for pointer types which will be used as [`Pin`]ning pointers
636//!
637//! It should further be noted that creating a pinning pointer of some type `Ptr` *also* carries
638//! with it implications on the way that `Ptr` type must implement [`Drop`]
639//! (as well as [`Deref`] and [`DerefMut`])! When implementing a pointer type that may be used as
640//! a pinning pointer, you must also take the same care described above not to *move* out of or
641//! otherwise invalidate the pointee during [`Drop`], [`Deref`], or [`DerefMut`]
642//! implementations.
643//!
644//! ## "Assigning" pinned data
645//!
646//! Although in general it is not valid to swap data or assign through a [`Pin<Ptr>`] for the same
647//! reason that reusing a pinned object's memory is invalid, it is possible to do validly when
648//! implemented with special care for the needs of the exact data structure which is being
649//! modified. For example, the assigning function must know how to update all uses of the pinned
650//! address (and any other invariants necessary to satisfy validity for that type). For
651//! [`Unmovable`] (from the example above), we could write an assignment function like so:
652//!
653//! ```
654//! # use std::pin::Pin;
655//! # use std::marker::PhantomPinned;
656//! # use std::ptr::NonNull;
657//! # struct Unmovable {
658//! # data: [u8; 64],
659//! # slice: NonNull<[u8]>,
660//! # _pin: PhantomPinned,
661//! # }
662//! #
663//! impl Unmovable {
664//! // Copies the contents of `src` into `self`, fixing up the self-pointer
665//! // in the process.
666//! fn assign(self: Pin<&mut Self>, src: Pin<&mut Self>) {
667//! unsafe {
668//! let unpinned_self = Pin::into_inner_unchecked(self);
669//! let unpinned_src = Pin::into_inner_unchecked(src);
670//! *unpinned_self = Self {
671//! data: unpinned_src.data,
672//! slice: NonNull::from(&mut []),
673//! _pin: PhantomPinned,
674//! };
675//!
676//! let data_ptr = unpinned_src.data.as_ptr() as *const u8;
677//! let slice_ptr = unpinned_src.slice.as_ptr() as *const u8;
678//! let offset = slice_ptr.offset_from(data_ptr) as usize;
679//! let len = (*unpinned_src.slice.as_ptr()).len();
680//!
681//! unpinned_self.slice = NonNull::from(&mut unpinned_self.data[offset..offset+len]);
682//! }
683//! }
684//! }
685//! ```
686//!
687//! Even though we can't have the compiler do the assignment for us, it's possible to write
688//! such specialized functions for types that might need it.
689//!
690//! Note that it _is_ possible to assign generically through a [`Pin<Ptr>`] by way of [`Pin::set()`].
691//! This does not violate any guarantees, since it will run [`drop`] on the pointee value before
692//! assigning the new value. Thus, the [`drop`] implementation still has a chance to perform the
693//! necessary notifications to dependent values before the memory location of the original pinned
694//! value is overwritten.
695//!
696//! ## Projections and Structural Pinning
697//! [structural-pinning]: self#projections-and-structural-pinning
698//!
699//! With ordinary structs, it is natural that we want to add *projection* methods that allow
700//! borrowing one or more of the inner fields of a struct when the caller has access to a
701//! borrow of the whole struct:
702//!
703//! ```
704//! # struct Field;
705//! struct Struct {
706//! field: Field,
707//! // ...
708//! }
709//!
710//! impl Struct {
711//! fn field(&mut self) -> &mut Field { &mut self.field }
712//! }
713//! ```
714//!
715//! When working with address-sensitive types, it's not obvious what the signature of these
716//! functions should be. If `field` takes <code>self: [Pin]<[&mut Struct][&mut]></code>, should it
717//! return [`&mut Field`] or <code>[Pin]<[`&mut Field`]></code>? This question also arises with
718//! `enum`s and wrapper types like [`Vec<T>`], [`Box<T>`], and [`RefCell<T>`]. (This question
719//! applies just as well to shared references, but we'll examine the more common case of mutable
720//! references for illustration)
721//!
722//! It turns out that it's up to the author of `Struct` to decide which type the "projection"
723//! should produce. The choice must be *consistent* though: if a pin is projected to a field
724//! in one place, then it should very likely not be exposed elsewhere without projecting the
725//! pin.
726//!
727//! As the author of a data structure, you get to decide for each field whether pinning
728//! "propagates" to this field or not. Pinning that propagates is also called "structural",
729//! because it follows the structure of the type.
730//!
731//! This choice depends on what guarantees you need from the field for your [`unsafe`] code to work.
732//! If the field is itself address-sensitive, or participates in the parent struct's address
733//! sensitivity, it will need to be structurally pinned.
734//!
735//! A useful test is if [`unsafe`] code that consumes <code>[Pin]\<[&mut Struct][&mut]></code>
736//! also needs to take note of the address of the field itself, it may be evidence that that field
737//! is structurally pinned. Unfortunately, there are no hard-and-fast rules.
738//!
739//! ### Choosing pinning *not to be* structural for `field`...
740//!
741//! While counter-intuitive, it's often the easier choice: if you do not expose a
742//! <code>[Pin]<[&mut] Field></code>, you do not need to be careful about other code
743//! moving out of that field, you just have to ensure is that you never create pinning
744//! reference to that field. This does of course also mean that if you decide a field does not
745//! have structural pinning, you must not write [`unsafe`] code that assumes (invalidly) that the
746//! field *is* structurally pinned!
747//!
748//! Fields without structural pinning may have a projection method that turns
749//! <code>[Pin]<[&mut] Struct></code> into [`&mut Field`]:
750//!
751//! ```rust,no_run
752//! # use std::pin::Pin;
753//! # type Field = i32;
754//! # struct Struct { field: Field }
755//! impl Struct {
756//! fn field(self: Pin<&mut Self>) -> &mut Field {
757//! // This is okay because `field` is never considered pinned, therefore we do not
758//! // need to uphold any pinning guarantees for this field in particular. Of course,
759//! // we must not elsewhere assume this field *is* pinned if we choose to expose
760//! // such a method!
761//! unsafe { &mut self.get_unchecked_mut().field }
762//! }
763//! }
764//! ```
765//!
766//! You may also in this situation <code>impl [Unpin] for Struct {}</code> *even if* the type of
767//! `field` is not [`Unpin`]. Since we have explicitly chosen not to care about pinning guarantees
768//! for `field`, the way `field`'s type interacts with pinning is no longer relevant in the
769//! context of its use in `Struct`.
770//!
771//! ### Choosing pinning *to be* structural for `field`...
772//!
773//! The other option is to decide that pinning is "structural" for `field`,
774//! meaning that if the struct is pinned then so is the field.
775//!
776//! This allows writing a projection that creates a <code>[Pin]<[`&mut Field`]></code>, thus
777//! witnessing that the field is pinned:
778//!
779//! ```rust,no_run
780//! # use std::pin::Pin;
781//! # type Field = i32;
782//! # struct Struct { field: Field }
783//! impl Struct {
784//! fn field(self: Pin<&mut Self>) -> Pin<&mut Field> {
785//! // This is okay because `field` is pinned when `self` is.
786//! unsafe { self.map_unchecked_mut(|s| &mut s.field) }
787//! }
788//! }
789//! ```
790//!
791//! Structural pinning comes with a few extra requirements:
792//!
793//! 1. *Structural [`Unpin`].* A struct can be [`Unpin`] only if all of its
794//! structurally-pinned fields are, too. This is [`Unpin`]'s behavior by default.
795//! However, as a libray author, it is your responsibility not to write something like
796//! <code>impl\<T> [Unpin] for Struct\<T> {}</code> and then offer a method that provides
797//! structural pinning to an inner field of `T`, which may not be [`Unpin`]! (Adding *any*
798//! projection operation requires unsafe code, so the fact that [`Unpin`] is a safe trait does
799//! not break the principle that you only have to worry about any of this if you use
800//! [`unsafe`])
801//!
802//! 2. *Pinned Destruction.* As discussed [above][drop-impl], [`drop`] takes
803//! [`&mut self`], but the struct (and hence its fields) might have been pinned
804//! before. The destructor must be written as if its argument was
805//! <code>self: [Pin]\<[`&mut Self`]></code>, instead.
806//!
807//! As a consequence, the struct *must not* be [`#[repr(packed)]`][packed].
808//!
809//! 3. *Structural Notice of Destruction.* You must uphold the the
810//! [`Drop` guarantee][drop-guarantee]: once your struct is pinned, the struct's storage cannot
811//! be re-used without calling the structurally-pinned fields' destructors, as well.
812//!
813//! This can be tricky, as witnessed by [`VecDeque<T>`]: the destructor of [`VecDeque<T>`]
814//! can fail to call [`drop`] on all elements if one of the destructors panics. This violates
815//! the [`Drop` guarantee][drop-guarantee], because it can lead to elements being deallocated
816//! without their destructor being called.
817//!
818//! [`VecDeque<T>`] has no pinning projections, so its destructor is sound. If it wanted
819//! to provide such structural pinning, its destructor would need to abort the process if any
820//! of the destructors panicked.
821//!
822//! 4. You must not offer any other operations that could lead to data being *moved* out of
823//! the structural fields when your type is pinned. For example, if the struct contains an
824//! [`Option<T>`] and there is a [`take`][Option::take]-like operation with type
825//! <code>fn([Pin]<[&mut Struct\<T>][&mut]>) -> [`Option<T>`]</code>,
826//! then that operation can be used to move a `T` out of a pinned `Struct<T>` – which
827//! means pinning cannot be structural for the field holding this data.
828//!
829//! For a more complex example of moving data out of a pinned type,
830//! imagine if [`RefCell<T>`] had a method
831//! <code>fn get_pin_mut(self: [Pin]<[`&mut Self`]>) -> [Pin]<[`&mut T`]></code>.
832//! Then we could do the following:
833//! ```compile_fail
834//! # use std::cell::RefCell;
835//! # use std::pin::Pin;
836//! fn exploit_ref_cell<T>(rc: Pin<&mut RefCell<T>>) {
837//! // Here we get pinned access to the `T`.
838//! let _: Pin<&mut T> = rc.as_mut().get_pin_mut();
839//!
840//! // And here we have `&mut T` to the same data.
841//! let shared: &RefCell<T> = rc.into_ref().get_ref();
842//! let borrow = shared.borrow_mut();
843//! let content = &mut *borrow;
844//! }
845//! ```
846//! This is catastrophic: it means we can first pin the content of the
847//! [`RefCell<T>`] (using <code>[RefCell]::get_pin_mut</code>) and then move that
848//! content using the mutable reference we got later.
849//!
850//! ### Structural Pinning examples
851//!
852//! For a type like [`Vec<T>`], both possibilities (structural pinning or not) make
853//! sense. A [`Vec<T>`] with structural pinning could have `get_pin`/`get_pin_mut`
854//! methods to get pinning references to elements. However, it could *not* allow calling
855//! [`pop`][Vec::pop] on a pinned [`Vec<T>`] because that would move the (structurally
856//! pinned) contents! Nor could it allow [`push`][Vec::push], which might reallocate and thus also
857//! move the contents.
858//!
859//! A [`Vec<T>`] without structural pinning could
860//! <code>impl\<T> [Unpin] for [`Vec<T>`]</code>, because the contents are never pinned
861//! and the [`Vec<T>`] itself is fine with being moved as well.
862//! At that point pinning just has no effect on the vector at all.
863//!
864//! In the standard library, pointer types generally do not have structural pinning,
865//! and thus they do not offer pinning projections. This is why <code>[`Box<T>`]: [Unpin]</code>
866//! holds for all `T`. It makes sense to do this for pointer types, because moving the
867//! [`Box<T>`] does not actually move the `T`: the [`Box<T>`] can be freely
868//! movable (aka [`Unpin`]) even if the `T` is not. In fact, even <code>[Pin]<[`Box<T>`]></code> and
869//! <code>[Pin]<[`&mut T`]></code> are always [`Unpin`] themselves, for the same reason:
870//! their contents (the `T`) are pinned, but the pointers themselves can be moved without moving
871//! the pinned data. For both [`Box<T>`] and <code>[Pin]<[`Box<T>`]></code>,
872//! whether the content is pinned is entirely independent of whether the
873//! pointer is pinned, meaning pinning is *not* structural.
874//!
875//! When implementing a [`Future`] combinator, you will usually need structural pinning
876//! for the nested futures, as you need to get pinning ([`Pin`]-wrapped) references to them to
877//! call [`poll`]. But if your combinator contains any other data that does not need to be pinned,
878//! you can make those fields not structural and hence freely access them with a
879//! mutable reference even when you just have <code>[Pin]<[`&mut Self`]></code>
880//! (such as in your own [`poll`] implementation).
881//!
882//! [`&mut T`]: &mut
883//! [`&mut self`]: &mut
884//! [`&mut Self`]: &mut
885//! [`&mut Field`]: &mut
886//! [Deref]: crate::ops::Deref "ops::Deref"
887//! [`Deref`]: crate::ops::Deref "ops::Deref"
888//! [Target]: crate::ops::Deref::Target "ops::Deref::Target"
889//! [`DerefMut`]: crate::ops::DerefMut "ops::DerefMut"
890//! [`mem::swap`]: crate::mem::swap "mem::swap"
891//! [`mem::forget`]: crate::mem::forget "mem::forget"
892//! [ManuallyDrop]: crate::mem::ManuallyDrop "ManuallyDrop"
893//! [RefCell]: crate::cell::RefCell "cell::RefCell"
894//! [`drop`]: Drop::drop
895//! [`ptr::write`]: crate::ptr::write "ptr::write"
896//! [`Future`]: crate::future::Future "future::Future"
897//! [drop-impl]: #drop-implementation
898//! [drop-guarantee]: #drop-guarantee
899//! [`poll`]: crate::future::Future::poll "future::Future::poll"
900//! [&]: reference "shared reference"
901//! [&mut]: reference "mutable reference"
902//! [`unsafe`]: ../../std/keyword.unsafe.html "keyword unsafe"
903//! [packed]: https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked
904//! [`std::alloc`]: ../../std/alloc/index.html
905//! [`Box<T>`]: ../../std/boxed/struct.Box.html
906//! [Box]: ../../std/boxed/struct.Box.html "Box"
907//! [`Box`]: ../../std/boxed/struct.Box.html "Box"
908//! [`Rc<T>`]: ../../std/rc/struct.Rc.html
909//! [Rc]: ../../std/rc/struct.Rc.html "rc::Rc"
910//! [`Vec<T>`]: ../../std/vec/struct.Vec.html
911//! [Vec]: ../../std/vec/struct.Vec.html "Vec"
912//! [`Vec`]: ../../std/vec/struct.Vec.html "Vec"
913//! [`Vec::set_len`]: ../../std/vec/struct.Vec.html#method.set_len "Vec::set_len"
914//! [Vec::pop]: ../../std/vec/struct.Vec.html#method.pop "Vec::pop"
915//! [Vec::push]: ../../std/vec/struct.Vec.html#method.push "Vec::push"
916//! [`Vec::set_len`]: ../../std/vec/struct.Vec.html#method.set_len
917//! [`VecDeque<T>`]: ../../std/collections/struct.VecDeque.html
918//! [VecDeque]: ../../std/collections/struct.VecDeque.html "collections::VecDeque"
919//! [`String`]: ../../std/string/struct.String.html "String"
920
921#![stable(feature = "pin", since = "1.33.0")]
922
923use crate::cmp;
924use crate::fmt;
925use crate::hash::{Hash, Hasher};
926use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn, Receiver};
927
928#[allow(unused_imports)]
929use crate::{
930 cell::{RefCell, UnsafeCell},
931 future::Future,
932 marker::PhantomPinned,
933 mem, ptr,
934};
935
936/// A pointer which pins its pointee in place.
937///
938/// [`Pin`] is a wrapper around some kind of pointer `Ptr` which makes that pointer "pin" its
939/// pointee value in place, thus preventing the value referenced by that pointer from being moved
940/// or otherwise invalidated at that place in memory unless it implements [`Unpin`].
941///
942/// *See the [`pin` module] documentation for a more thorough exploration of pinning.*
943///
944/// ## Pinning values with [`Pin<Ptr>`]
945///
946/// In order to pin a value, we wrap a *pointer to that value* (of some type `Ptr`) in a
947/// [`Pin<Ptr>`]. [`Pin<Ptr>`] can wrap any pointer type, forming a promise that the **pointee**
948/// will not be *moved* or [otherwise invalidated][subtle-details]. If the pointee value's type
949/// implements [`Unpin`], we are free to disregard these requirements entirely and can wrap any
950/// pointer to that value in [`Pin`] directly via [`Pin::new`]. If the pointee value's type does
951/// not implement [`Unpin`], then Rust will not let us use the [`Pin::new`] function directly and
952/// we'll need to construct a [`Pin`]-wrapped pointer in one of the more specialized manners
953/// discussed below.
954///
955/// We call such a [`Pin`]-wrapped pointer a **pinning pointer** (or pinning ref, or pinning
956/// [`Box`], etc.) because its existince is the thing that is pinning the underlying pointee in
957/// place: it is the metaphorical "pin" securing the data in place on the pinboard (in memory).
958///
959/// It is important to stress that the thing in the [`Pin`] is not the value which we want to pin
960/// itself, but rather a pointer to that value! A [`Pin<Ptr>`] does not pin the `Ptr` but rather
961/// the pointer's ***pointee** value*.
962///
963/// The most common set of types which require pinning related guarantees for soundness are the
964/// compiler-generated state machines that implement [`Future`] for the return value of
965/// `async fn`s. These compiler-generated [`Future`]s may contain self-referrential pointers, one
966/// of the most common use cases for [`Pin`]. More details on this point are provided in the
967/// [`pin` module] docs, but suffice it to say they require the guarantees provided by pinning to
968/// be implemented soundly.
969///
970/// This requirement for the implementation of `async fn`s means that the [`Future`] trait
971/// requires all calls to [`poll`] to use a <code>self: [Pin]\<&mut Self></code> parameter instead
972/// of the usual `&mut self`. Therefore, when manually polling a future, you will need to pin it
973/// first.
974///
975/// You may notice that `async fn`-sourced [`Future`]s are only a small percentage of all
976/// [`Future`]s that exist, yet we had to modify the signature of [`poll`] for all [`Future`]s
977/// to accommodate them. This is unfortunate, but there is a way that the language attempts to
978/// alleviate the extra friction that this API choice incurs: the [`Unpin`] trait.
979///
980/// The vast majority of Rust types have no reason to ever care about being pinned. These
981/// types implement the [`Unpin`] trait, which entirely opts all values of that type out of
982/// pinning-related guarantees. For values of these types, pinning a value by pointing to it with a
983/// [`Pin<Ptr>`] will have no actual effect.
984///
985/// The reason this distinction exists is exactly to allow APIs like [`Future::poll`] to take a
986/// [`Pin<Ptr>`] as an argument for all types while only forcing [`Future`] types that actually
987/// care about pinning guarantees pay the ergonomics cost. For the majority of [`Future`] types
988/// that don't have a reason to care about being pinned and therefore implement [`Unpin`], the
989/// <code>[Pin]\<&mut Self></code> will act exactly like a regular `&mut Self`, allowing direct
990/// access to the underlying value. Only types that *don't* implement [`Unpin`] will be restricted.
991///
992/// ### Pinning a value of a type that implements [`Unpin`]
993///
994/// If the type of the value you need to "pin" implements [`Unpin`], you can trivially wrap any
995/// pointer to that value in a [`Pin`] by calling [`Pin::new`].
996///
997/// ```
998/// use std::pin::Pin;
999///
1000/// // Create a value of a type that implements `Unpin`
1001/// let mut unpin_future = std::future::ready(5);
1002///
1003/// // Pin it by creating a pinning mutable reference to it (ready to be `poll`ed!)
1004/// let my_pinned_unpin_future: Pin<&mut _> = Pin::new(&mut unpin_future);
1005/// ```
1006///
1007/// ### Pinning a value inside a [`Box`]
1008///
1009/// The simplest and most flexible way to pin a value that does not implement [`Unpin`] is to put
1010/// that value inside a [`Box`] and then turn that [`Box`] into a "pinning [`Box`]" by wrapping it
1011/// in a [`Pin`]. You can do both of these in a single step using [`Box::pin`]. Let's see an
1012/// example of using this flow to pin a [`Future`] returned from calling an `async fn`, a common
1013/// use case as described above.
1014///
1015/// ```
1016/// use std::pin::Pin;
1017///
1018/// async fn add_one(x: u32) -> u32 {
1019/// x + 1
1020/// }
1021///
1022/// // Call the async function to get a future back
1023/// let fut = add_one(42);
1024///
1025/// // Pin the future inside a pinning box
1026/// let pinned_fut: Pin<Box<_>> = Box::pin(fut);
1027/// ```
1028///
1029/// If you have a value which is already boxed, for example a [`Box<dyn Future>`][Box], you can pin
1030/// that value in-place at its current memory address using [`Box::into_pin`].
1031///
1032/// ```
1033/// use std::pin::Pin;
1034/// use std::future::Future;
1035///
1036/// async fn add_one(x: u32) -> u32 {
1037/// x + 1
1038/// }
1039///
1040/// fn boxed_add_one(x: u32) -> Box<dyn Future<Output = u32>> {
1041/// Box::new(add_one(x))
1042/// }
1043///
1044/// let boxed_fut = boxed_add_one(42);
1045///
1046/// // Pin the future inside the existing box
1047/// let pinned_fut: Pin<Box<_>> = Box::into_pin(boxed_fut);
1048/// ```
1049///
1050/// There are similar pinning methods offered on the other standard library smart pointer types
1051/// as well, like [`Rc`] and [`Arc`].
1052///
1053/// ### Pinning a value on the stack using [`pin!`]
1054///
1055/// There are some situations where it is desirable or even required (for example, in a `#[no_std]`
1056/// context where you don't have access to the standard library or allocation in general) to
1057/// pin a value which does not implement [`Unpin`] to its location on the stack. Doing so is
1058/// possible using the [`pin!`] macro. See its documentation for more.
1059///
1060/// ## Layout and ABI
1061///
1062/// [`Pin<Ptr>`] is guaranteed to have the same memory layout and ABI[^noalias] as `Ptr`.
1063///
1064/// [^noalias]: There is a bit of nuance here that is still being decided about whether the
1065/// aliasing semantics of `Pin<&mut T>` should be different than `&mut T`, but this is true as of
1066/// today.
1067///
1068/// [`pin!`]: crate::pin::pin "pin!"
1069/// [`Future`]: crate::future::Future "Future"
1070/// [`poll`]: crate::future::Future::poll "Future::poll"
1071/// [`Future::poll`]: crate::future::Future::poll "Future::poll"
1072/// [`pin` module]: self "pin module"
1073/// [`Rc`]: ../../std/rc/struct.Rc.html "Rc"
1074/// [`Arc`]: ../../std/sync/struct.Arc.html "Arc"
1075/// [Box]: ../../std/boxed/struct.Box.html "Box"
1076/// [`Box`]: ../../std/boxed/struct.Box.html "Box"
1077/// [`Box::pin`]: ../../std/boxed/struct.Box.html#method.pin "Box::pin"
1078/// [`Box::into_pin`]: ../../std/boxed/struct.Box.html#method.into_pin "Box::into_pin"
1079/// [subtle-details]: self#subtle-details-and-the-drop-guarantee "pin subtle details"
1080/// [`unsafe`]: ../../std/keyword.unsafe.html "keyword unsafe"
1081//
1082// Note: the `Clone` derive below causes unsoundness as it's possible to implement
1083// `Clone` for mutable references.
1084// See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311> for more details.
1085#[stable(feature = "pin", since = "1.33.0")]
1086#[lang = "pin"]
1087#[fundamental]
1088#[repr(transparent)]
1089#[derive(Copy, Clone)]
1090pub struct Pin<Ptr> {
1091 // FIXME(#93176): this field is made `#[unstable] #[doc(hidden)] pub` to:
1092 // - deter downstream users from accessing it (which would be unsound!),
1093 // - let the `pin!` macro access it (such a macro requires using struct
1094 // literal syntax in order to benefit from lifetime extension).
1095 //
1096 // However, if the `Deref` impl exposes a field with the same name as this
1097 // field, then the two will collide, resulting in a confusing error when the
1098 // user attempts to access the field through a `Pin<Ptr>`. Therefore, the
1099 // name `__pointer` is designed to be unlikely to collide with any other
1100 // field. Long-term, macro hygiene is expected to offer a more robust
1101 // alternative, alongside `unsafe` fields.
1102 #[unstable(feature = "unsafe_pin_internals", issue = "none")]
1103 #[doc(hidden)]
1104 pub __pointer: Ptr,
1105}
1106
1107// The following implementations aren't derived in order to avoid soundness
1108// issues. `&self.__pointer` should not be accessible to untrusted trait
1109// implementations.
1110//
1111// See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73> for more details.
1112
1113#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1114impl<Ptr: Deref, Q: Deref> PartialEq<Pin<Q>> for Pin<Ptr>
1115where
1116 Ptr::Target: PartialEq<Q::Target>,
1117{
1118 fn eq(&self, other: &Pin<Q>) -> bool {
1119 Ptr::Target::eq(self, other)
1120 }
1121
1122 fn ne(&self, other: &Pin<Q>) -> bool {
1123 Ptr::Target::ne(self, other)
1124 }
1125}
1126
1127#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1128impl<Ptr: Deref<Target: Eq>> Eq for Pin<Ptr> {}
1129
1130#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1131impl<Ptr: Deref, Q: Deref> PartialOrd<Pin<Q>> for Pin<Ptr>
1132where
1133 Ptr::Target: PartialOrd<Q::Target>,
1134{
1135 fn partial_cmp(&self, other: &Pin<Q>) -> Option<cmp::Ordering> {
1136 Ptr::Target::partial_cmp(self, other)
1137 }
1138
1139 fn lt(&self, other: &Pin<Q>) -> bool {
1140 Ptr::Target::lt(self, other)
1141 }
1142
1143 fn le(&self, other: &Pin<Q>) -> bool {
1144 Ptr::Target::le(self, other)
1145 }
1146
1147 fn gt(&self, other: &Pin<Q>) -> bool {
1148 Ptr::Target::gt(self, other)
1149 }
1150
1151 fn ge(&self, other: &Pin<Q>) -> bool {
1152 Ptr::Target::ge(self, other)
1153 }
1154}
1155
1156#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1157impl<Ptr: Deref<Target: Ord>> Ord for Pin<Ptr> {
1158 fn cmp(&self, other: &Self) -> cmp::Ordering {
1159 Ptr::Target::cmp(self, other)
1160 }
1161}
1162
1163#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1164impl<Ptr: Deref<Target: Hash>> Hash for Pin<Ptr> {
1165 fn hash<H: Hasher>(&self, state: &mut H) {
1166 Ptr::Target::hash(self, state);
1167 }
1168}
1169
1170impl<Ptr: Deref<Target: Unpin>> Pin<Ptr> {
1171 /// Construct a new `Pin<Ptr>` around a pointer to some data of a type that
1172 /// implements [`Unpin`].
1173 ///
1174 /// Unlike `Pin::new_unchecked`, this method is safe because the pointer
1175 /// `Ptr` dereferences to an [`Unpin`] type, which cancels the pinning guarantees.
1176 ///
1177 /// # Examples
1178 ///
1179 /// ```
1180 /// use std::pin::Pin;
1181 ///
1182 /// let mut val: u8 = 5;
1183 ///
1184 /// // Since `val` doesn't care about being moved, we can safely create a "facade" `Pin`
1185 /// // which will allow `val` to participate in `Pin`-bound apis without checking that
1186 /// // pinning guarantees are actually upheld.
1187 /// let mut pinned: Pin<&mut u8> = Pin::new(&mut val);
1188 /// ```
1189 #[inline(always)]
1190 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1191 #[stable(feature = "pin", since = "1.33.0")]
1192 pub const fn new(pointer: Ptr) -> Pin<Ptr> {
1193 // SAFETY: the value pointed to is `Unpin`, and so has no requirements
1194 // around pinning.
1195 unsafe { Pin::new_unchecked(pointer) }
1196 }
1197
1198 /// Unwraps this `Pin<Ptr>`, returning the underlying pointer.
1199 ///
1200 /// Doing this operation safely requires that the data pointed at by this pinning pointer
1201 /// implemts [`Unpin`] so that we can ignore the pinning invariants when unwrapping it.
1202 ///
1203 /// # Examples
1204 ///
1205 /// ```
1206 /// use std::pin::Pin;
1207 ///
1208 /// let mut val: u8 = 5;
1209 /// let pinned: Pin<&mut u8> = Pin::new(&mut val);
1210 ///
1211 /// // Unwrap the pin to get the underlying mutable reference to the value. We can do
1212 /// // this because `val` doesn't care about being moved, so the `Pin` was just
1213 /// // a "facade" anyway.
1214 /// let r = Pin::into_inner(pinned);
1215 /// assert_eq!(*r, 5);
1216 /// ```
1217 #[inline(always)]
1218 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1219 #[stable(feature = "pin_into_inner", since = "1.39.0")]
1220 pub const fn into_inner(pin: Pin<Ptr>) -> Ptr {
1221 pin.__pointer
1222 }
1223}
1224
1225impl<Ptr: Deref> Pin<Ptr> {
1226 /// Construct a new `Pin<Ptr>` around a reference to some data of a type that
1227 /// may or may not implement [`Unpin`].
1228 ///
1229 /// If `pointer` dereferences to an [`Unpin`] type, [`Pin::new`] should be used
1230 /// instead.
1231 ///
1232 /// # Safety
1233 ///
1234 /// This constructor is unsafe because we cannot guarantee that the data
1235 /// pointed to by `pointer` is pinned. At its core, pinning a value means making the
1236 /// guarantee that the value's data will not be moved nor have its storage invalidated until
1237 /// it gets dropped. For a more thorough explanation of pinning, see the [`pin` module docs].
1238 ///
1239 /// If the caller that is constructing this `Pin<Ptr>` does not ensure that the data `Ptr`
1240 /// points to is pinned, that is a violation of the API contract and may lead to undefined
1241 /// behavior in later (even safe) operations.
1242 ///
1243 /// By using this method, you are also making a promise about the [`Deref`] and
1244 /// [`DerefMut`] implementations of `Ptr`, if they exist. Most importantly, they
1245 /// must not move out of their `self` arguments: `Pin::as_mut` and `Pin::as_ref`
1246 /// will call `DerefMut::deref_mut` and `Deref::deref` *on the pointer type `Ptr`*
1247 /// and expect these methods to uphold the pinning invariants.
1248 /// Moreover, by calling this method you promise that the reference `Ptr`
1249 /// dereferences to will not be moved out of again; in particular, it
1250 /// must not be possible to obtain a `&mut Ptr::Target` and then
1251 /// move out of that reference (using, for example [`mem::swap`]).
1252 ///
1253 /// For example, calling `Pin::new_unchecked` on an `&'a mut T` is unsafe because
1254 /// while you are able to pin it for the given lifetime `'a`, you have no control
1255 /// over whether it is kept pinned once `'a` ends, and therefore cannot uphold the
1256 /// guarantee that a value, once pinned, remains pinned until it is dropped:
1257 ///
1258 /// ```
1259 /// use std::mem;
1260 /// use std::pin::Pin;
1261 ///
1262 /// fn move_pinned_ref<T>(mut a: T, mut b: T) {
1263 /// unsafe {
1264 /// let p: Pin<&mut T> = Pin::new_unchecked(&mut a);
1265 /// // This should mean the pointee `a` can never move again.
1266 /// }
1267 /// mem::swap(&mut a, &mut b); // Potential UB down the road ⚠️
1268 /// // The address of `a` changed to `b`'s stack slot, so `a` got moved even
1269 /// // though we have previously pinned it! We have violated the pinning API contract.
1270 /// }
1271 /// ```
1272 /// A value, once pinned, must remain pinned until it is dropped (unless its type implements
1273 /// `Unpin`). Because `Pin<&mut T>` does not own the value, dropping the `Pin` will not drop
1274 /// the value and will not end the pinning contract. So moving the value after dropping the
1275 /// `Pin<&mut T>` is still a violation of the API contract.
1276 ///
1277 /// Similarly, calling `Pin::new_unchecked` on an `Rc<T>` is unsafe because there could be
1278 /// aliases to the same data that are not subject to the pinning restrictions:
1279 /// ```
1280 /// use std::rc::Rc;
1281 /// use std::pin::Pin;
1282 ///
1283 /// fn move_pinned_rc<T>(mut x: Rc<T>) {
1284 /// // This should mean the pointee can never move again.
1285 /// let pin = unsafe { Pin::new_unchecked(Rc::clone(&x)) };
1286 /// {
1287 /// let p: Pin<&T> = pin.as_ref();
1288 /// // ...
1289 /// }
1290 /// drop(pin);
1291 ///
1292 /// let content = Rc::get_mut(&mut x).unwrap(); // Potential UB down the road ⚠️
1293 /// // Now, if `x` was the only reference, we have a mutable reference to
1294 /// // data that we pinned above, which we could use to move it as we have
1295 /// // seen in the previous example. We have violated the pinning API contract.
1296 /// }
1297 /// ```
1298 ///
1299 /// ## Pinning of closure captures
1300 ///
1301 /// Particular care is required when using `Pin::new_unchecked` in a closure:
1302 /// `Pin::new_unchecked(&mut var)` where `var` is a by-value (moved) closure capture
1303 /// implicitly makes the promise that the closure itself is pinned, and that *all* uses
1304 /// of this closure capture respect that pinning.
1305 /// ```
1306 /// use std::pin::Pin;
1307 /// use std::task::Context;
1308 /// use std::future::Future;
1309 ///
1310 /// fn move_pinned_closure(mut x: impl Future, cx: &mut Context<'_>) {
1311 /// // Create a closure that moves `x`, and then internally uses it in a pinned way.
1312 /// let mut closure = move || unsafe {
1313 /// let _ignore = Pin::new_unchecked(&mut x).poll(cx);
1314 /// };
1315 /// // Call the closure, so the future can assume it has been pinned.
1316 /// closure();
1317 /// // Move the closure somewhere else. This also moves `x`!
1318 /// let mut moved = closure;
1319 /// // Calling it again means we polled the future from two different locations,
1320 /// // violating the pinning API contract.
1321 /// moved(); // Potential UB ⚠️
1322 /// }
1323 /// ```
1324 /// When passing a closure to another API, it might be moving the closure any time, so
1325 /// `Pin::new_unchecked` on closure captures may only be used if the API explicitly documents
1326 /// that the closure is pinned.
1327 ///
1328 /// The better alternative is to avoid all that trouble and do the pinning in the outer function
1329 /// instead (here using the [`pin!`][crate::pin::pin] macro):
1330 /// ```
1331 /// use std::pin::pin;
1332 /// use std::task::Context;
1333 /// use std::future::Future;
1334 ///
1335 /// fn move_pinned_closure(mut x: impl Future, cx: &mut Context<'_>) {
1336 /// let mut x = pin!(x);
1337 /// // Create a closure that captures `x: Pin<&mut _>`, which is safe to move.
1338 /// let mut closure = move || {
1339 /// let _ignore = x.as_mut().poll(cx);
1340 /// };
1341 /// // Call the closure, so the future can assume it has been pinned.
1342 /// closure();
1343 /// // Move the closure somewhere else.
1344 /// let mut moved = closure;
1345 /// // Calling it again here is fine (except that we might be polling a future that already
1346 /// // returned `Poll::Ready`, but that is a separate problem).
1347 /// moved();
1348 /// }
1349 /// ```
1350 ///
1351 /// [`mem::swap`]: crate::mem::swap
1352 /// [`pin` module docs]: self
1353 #[lang = "new_unchecked"]
1354 #[inline(always)]
1355 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1356 #[stable(feature = "pin", since = "1.33.0")]
1357 pub const unsafe fn new_unchecked(pointer: Ptr) -> Pin<Ptr> {
1358 Pin { __pointer: pointer }
1359 }
1360
1361 /// Gets a shared reference to the pinned value this [`Pin`] points to.
1362 ///
1363 /// This is a generic method to go from `&Pin<Pointer<T>>` to `Pin<&T>`.
1364 /// It is safe because, as part of the contract of `Pin::new_unchecked`,
1365 /// the pointee cannot move after `Pin<Pointer<T>>` got created.
1366 /// "Malicious" implementations of `Pointer::Deref` are likewise
1367 /// ruled out by the contract of `Pin::new_unchecked`.
1368 #[stable(feature = "pin", since = "1.33.0")]
1369 #[inline(always)]
1370 pub fn as_ref(&self) -> Pin<&Ptr::Target> {
1371 // SAFETY: see documentation on this function
1372 unsafe { Pin::new_unchecked(&*self.__pointer) }
1373 }
1374
1375 /// Unwraps this `Pin<Ptr>`, returning the underlying `Ptr`.
1376 ///
1377 /// # Safety
1378 ///
1379 /// This function is unsafe. You must guarantee that you will continue to
1380 /// treat the pointer `Ptr` as pinned after you call this function, so that
1381 /// the invariants on the `Pin` type can be upheld. If the code using the
1382 /// resulting `Ptr` does not continue to maintain the pinning invariants that
1383 /// is a violation of the API contract and may lead to undefined behavior in
1384 /// later (safe) operations.
1385 ///
1386 /// Note that you must be able to guarantee that the data pointed to by `Ptr`
1387 /// will be treated as pinned all the way until its `drop` handler is complete!
1388 ///
1389 /// *For more information, see the [`pin` module docs][self]*
1390 ///
1391 /// If the underlying data is [`Unpin`], [`Pin::into_inner`] should be used
1392 /// instead.
1393 #[inline(always)]
1394 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1395 #[stable(feature = "pin_into_inner", since = "1.39.0")]
1396 pub const unsafe fn into_inner_unchecked(pin: Pin<Ptr>) -> Ptr {
1397 pin.__pointer
1398 }
1399}
1400
1401impl<Ptr: DerefMut> Pin<Ptr> {
1402 /// Gets a mutable reference to the pinned value this `Pin<Ptr>` points to.
1403 ///
1404 /// This is a generic method to go from `&mut Pin<Pointer<T>>` to `Pin<&mut T>`.
1405 /// It is safe because, as part of the contract of `Pin::new_unchecked`,
1406 /// the pointee cannot move after `Pin<Pointer<T>>` got created.
1407 /// "Malicious" implementations of `Pointer::DerefMut` are likewise
1408 /// ruled out by the contract of `Pin::new_unchecked`.
1409 ///
1410 /// This method is useful when doing multiple calls to functions that consume the
1411 /// pinning pointer.
1412 ///
1413 /// # Example
1414 ///
1415 /// ```
1416 /// use std::pin::Pin;
1417 ///
1418 /// # struct Type {}
1419 /// impl Type {
1420 /// fn method(self: Pin<&mut Self>) {
1421 /// // do something
1422 /// }
1423 ///
1424 /// fn call_method_twice(mut self: Pin<&mut Self>) {
1425 /// // `method` consumes `self`, so reborrow the `Pin<&mut Self>` via `as_mut`.
1426 /// self.as_mut().method();
1427 /// self.as_mut().method();
1428 /// }
1429 /// }
1430 /// ```
1431 #[stable(feature = "pin", since = "1.33.0")]
1432 #[inline(always)]
1433 pub fn as_mut(&mut self) -> Pin<&mut Ptr::Target> {
1434 // SAFETY: see documentation on this function
1435 unsafe { Pin::new_unchecked(&mut *self.__pointer) }
1436 }
1437
1438 /// Assigns a new value to the memory location pointed to by the `Pin<Ptr>`.
1439 ///
1440 /// This overwrites pinned data, but that is okay: the original pinned value's destructor gets
1441 /// run before being overwritten and the new value is also a valid value of the same type, so
1442 /// no pinning invariant is violated. See [the `pin` module documentation][subtle-details]
1443 /// for more information on how this upholds the pinning invariants.
1444 ///
1445 /// # Example
1446 ///
1447 /// ```
1448 /// use std::pin::Pin;
1449 ///
1450 /// let mut val: u8 = 5;
1451 /// let mut pinned: Pin<&mut u8> = Pin::new(&mut val);
1452 /// println!("{}", pinned); // 5
1453 /// pinned.set(10);
1454 /// println!("{}", pinned); // 10
1455 /// ```
1456 ///
1457 /// [subtle-details]: self#subtle-details-and-the-drop-guarantee
1458 #[stable(feature = "pin", since = "1.33.0")]
1459 #[inline(always)]
1460 pub fn set(&mut self, value: Ptr::Target)
1461 where
1462 Ptr::Target: Sized,
1463 {
1464 *(self.__pointer) = value;
1465 }
1466}
1467
1468impl<'a, T: ?Sized> Pin<&'a T> {
1469 /// Constructs a new pin by mapping the interior value.
1470 ///
1471 /// For example, if you wanted to get a `Pin` of a field of something,
1472 /// you could use this to get access to that field in one line of code.
1473 /// However, there are several gotchas with these "pinning projections";
1474 /// see the [`pin` module] documentation for further details on that topic.
1475 ///
1476 /// # Safety
1477 ///
1478 /// This function is unsafe. You must guarantee that the data you return
1479 /// will not move so long as the argument value does not move (for example,
1480 /// because it is one of the fields of that value), and also that you do
1481 /// not move out of the argument you receive to the interior function.
1482 ///
1483 /// [`pin` module]: self#projections-and-structural-pinning
1484 #[stable(feature = "pin", since = "1.33.0")]
1485 pub unsafe fn map_unchecked<U, F>(self, func: F) -> Pin<&'a U>
1486 where
1487 U: ?Sized,
1488 F: FnOnce(&T) -> &U,
1489 {
1490 let pointer = &*self.__pointer;
1491 let new_pointer = func(pointer);
1492
1493 // SAFETY: the safety contract for `new_unchecked` must be
1494 // upheld by the caller.
1495 unsafe { Pin::new_unchecked(new_pointer) }
1496 }
1497
1498 /// Gets a shared reference out of a pin.
1499 ///
1500 /// This is safe because it is not possible to move out of a shared reference.
1501 /// It may seem like there is an issue here with interior mutability: in fact,
1502 /// it *is* possible to move a `T` out of a `&RefCell<T>`. However, this is
1503 /// not a problem as long as there does not also exist a `Pin<&T>` pointing
1504 /// to the inner `T` inside the `RefCell`, and `RefCell<T>` does not let you get a
1505 /// `Pin<&T>` pointer to its contents. See the discussion on ["pinning projections"]
1506 /// for further details.
1507 ///
1508 /// Note: `Pin` also implements `Deref` to the target, which can be used
1509 /// to access the inner value. However, `Deref` only provides a reference
1510 /// that lives for as long as the borrow of the `Pin`, not the lifetime of
1511 /// the reference contained in the `Pin`. This method allows turning the `Pin` into a reference
1512 /// with the same lifetime as the reference it wraps.
1513 ///
1514 /// ["pinning projections"]: self#projections-and-structural-pinning
1515 #[inline(always)]
1516 #[must_use]
1517 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1518 #[stable(feature = "pin", since = "1.33.0")]
1519 pub const fn get_ref(self) -> &'a T {
1520 self.__pointer
1521 }
1522}
1523
1524impl<'a, T: ?Sized> Pin<&'a mut T> {
1525 /// Converts this `Pin<&mut T>` into a `Pin<&T>` with the same lifetime.
1526 #[inline(always)]
1527 #[must_use = "`self` will be dropped if the result is not used"]
1528 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1529 #[stable(feature = "pin", since = "1.33.0")]
1530 pub const fn into_ref(self) -> Pin<&'a T> {
1531 Pin { __pointer: self.__pointer }
1532 }
1533
1534 /// Gets a mutable reference to the data inside of this `Pin`.
1535 ///
1536 /// This requires that the data inside this `Pin` is `Unpin`.
1537 ///
1538 /// Note: `Pin` also implements `DerefMut` to the data, which can be used
1539 /// to access the inner value. However, `DerefMut` only provides a reference
1540 /// that lives for as long as the borrow of the `Pin`, not the lifetime of
1541 /// the `Pin` itself. This method allows turning the `Pin` into a reference
1542 /// with the same lifetime as the original `Pin`.
1543 #[inline(always)]
1544 #[must_use = "`self` will be dropped if the result is not used"]
1545 #[stable(feature = "pin", since = "1.33.0")]
1546 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1547 pub const fn get_mut(self) -> &'a mut T
1548 where
1549 T: Unpin,
1550 {
1551 self.__pointer
1552 }
1553
1554 /// Gets a mutable reference to the data inside of this `Pin`.
1555 ///
1556 /// # Safety
1557 ///
1558 /// This function is unsafe. You must guarantee that you will never move
1559 /// the data out of the mutable reference you receive when you call this
1560 /// function, so that the invariants on the `Pin` type can be upheld.
1561 ///
1562 /// If the underlying data is `Unpin`, `Pin::get_mut` should be used
1563 /// instead.
1564 #[inline(always)]
1565 #[must_use = "`self` will be dropped if the result is not used"]
1566 #[stable(feature = "pin", since = "1.33.0")]
1567 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1568 pub const unsafe fn get_unchecked_mut(self) -> &'a mut T {
1569 self.__pointer
1570 }
1571
1572 /// Construct a new pin by mapping the interior value.
1573 ///
1574 /// For example, if you wanted to get a `Pin` of a field of something,
1575 /// you could use this to get access to that field in one line of code.
1576 /// However, there are several gotchas with these "pinning projections";
1577 /// see the [`pin` module] documentation for further details on that topic.
1578 ///
1579 /// # Safety
1580 ///
1581 /// This function is unsafe. You must guarantee that the data you return
1582 /// will not move so long as the argument value does not move (for example,
1583 /// because it is one of the fields of that value), and also that you do
1584 /// not move out of the argument you receive to the interior function.
1585 ///
1586 /// [`pin` module]: self#projections-and-structural-pinning
1587 #[must_use = "`self` will be dropped if the result is not used"]
1588 #[stable(feature = "pin", since = "1.33.0")]
1589 pub unsafe fn map_unchecked_mut<U, F>(self, func: F) -> Pin<&'a mut U>
1590 where
1591 U: ?Sized,
1592 F: FnOnce(&mut T) -> &mut U,
1593 {
1594 // SAFETY: the caller is responsible for not moving the
1595 // value out of this reference.
1596 let pointer = unsafe { Pin::get_unchecked_mut(self) };
1597 let new_pointer = func(pointer);
1598 // SAFETY: as the value of `this` is guaranteed to not have
1599 // been moved out, this call to `new_unchecked` is safe.
1600 unsafe { Pin::new_unchecked(new_pointer) }
1601 }
1602}
1603
1604impl<T: ?Sized> Pin<&'static T> {
1605 /// Get a pinning reference from a `&'static` reference.
1606 ///
1607 /// This is safe because `T` is borrowed immutably for the `'static` lifetime, which
1608 /// never ends.
1609 #[stable(feature = "pin_static_ref", since = "1.61.0")]
1610 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1611 pub const fn static_ref(r: &'static T) -> Pin<&'static T> {
1612 // SAFETY: The 'static borrow guarantees the data will not be
1613 // moved/invalidated until it gets dropped (which is never).
1614 unsafe { Pin::new_unchecked(pointer:r) }
1615 }
1616}
1617
1618impl<'a, Ptr: DerefMut> Pin<&'a mut Pin<Ptr>> {
1619 /// Gets `Pin<&mut T>` to the underlying pinned value from this nested `Pin`-pointer.
1620 ///
1621 /// This is a generic method to go from `Pin<&mut Pin<Pointer<T>>>` to `Pin<&mut T>`. It is
1622 /// safe because the existence of a `Pin<Pointer<T>>` ensures that the pointee, `T`, cannot
1623 /// move in the future, and this method does not enable the pointee to move. "Malicious"
1624 /// implementations of `Ptr::DerefMut` are likewise ruled out by the contract of
1625 /// `Pin::new_unchecked`.
1626 #[unstable(feature = "pin_deref_mut", issue = "86918")]
1627 #[must_use = "`self` will be dropped if the result is not used"]
1628 #[inline(always)]
1629 pub fn as_deref_mut(self) -> Pin<&'a mut Ptr::Target> {
1630 // SAFETY: What we're asserting here is that going from
1631 //
1632 // Pin<&mut Pin<Ptr>>
1633 //
1634 // to
1635 //
1636 // Pin<&mut Ptr::Target>
1637 //
1638 // is safe.
1639 //
1640 // We need to ensure that two things hold for that to be the case:
1641 //
1642 // 1) Once we give out a `Pin<&mut Ptr::Target>`, an `&mut Ptr::Target` will not be given out.
1643 // 2) By giving out a `Pin<&mut Ptr::Target>`, we do not risk of violating
1644 // `Pin<&mut Pin<Ptr>>`
1645 //
1646 // The existence of `Pin<Ptr>` is sufficient to guarantee #1: since we already have a
1647 // `Pin<Ptr>`, it must already uphold the pinning guarantees, which must mean that
1648 // `Pin<&mut Ptr::Target>` does as well, since `Pin::as_mut` is safe. We do not have to rely
1649 // on the fact that `Ptr` is _also_ pinned.
1650 //
1651 // For #2, we need to ensure that code given a `Pin<&mut Ptr::Target>` cannot cause the
1652 // `Pin<Ptr>` to move? That is not possible, since `Pin<&mut Ptr::Target>` no longer retains
1653 // any access to the `Ptr` itself, much less the `Pin<Ptr>`.
1654 unsafe { self.get_unchecked_mut() }.as_mut()
1655 }
1656}
1657
1658impl<T: ?Sized> Pin<&'static mut T> {
1659 /// Get a pinning mutable reference from a static mutable reference.
1660 ///
1661 /// This is safe because `T` is borrowed for the `'static` lifetime, which
1662 /// never ends.
1663 #[stable(feature = "pin_static_ref", since = "1.61.0")]
1664 #[rustc_const_unstable(feature = "const_pin", issue = "76654")]
1665 pub const fn static_mut(r: &'static mut T) -> Pin<&'static mut T> {
1666 // SAFETY: The 'static borrow guarantees the data will not be
1667 // moved/invalidated until it gets dropped (which is never).
1668 unsafe { Pin::new_unchecked(pointer:r) }
1669 }
1670}
1671
1672#[stable(feature = "pin", since = "1.33.0")]
1673impl<Ptr: Deref> Deref for Pin<Ptr> {
1674 type Target = Ptr::Target;
1675 fn deref(&self) -> &Ptr::Target {
1676 Pin::get_ref(self:Pin::as_ref(self))
1677 }
1678}
1679
1680#[stable(feature = "pin", since = "1.33.0")]
1681impl<Ptr: DerefMut<Target: Unpin>> DerefMut for Pin<Ptr> {
1682 fn deref_mut(&mut self) -> &mut Ptr::Target {
1683 Pin::get_mut(self:Pin::as_mut(self))
1684 }
1685}
1686
1687#[unstable(feature = "receiver_trait", issue = "none")]
1688impl<Ptr: Receiver> Receiver for Pin<Ptr> {}
1689
1690#[stable(feature = "pin", since = "1.33.0")]
1691impl<Ptr: fmt::Debug> fmt::Debug for Pin<Ptr> {
1692 fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1693 fmt::Debug::fmt(&self.__pointer, f)
1694 }
1695}
1696
1697#[stable(feature = "pin", since = "1.33.0")]
1698impl<Ptr: fmt::Display> fmt::Display for Pin<Ptr> {
1699 fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1700 fmt::Display::fmt(&self.__pointer, f)
1701 }
1702}
1703
1704#[stable(feature = "pin", since = "1.33.0")]
1705impl<Ptr: fmt::Pointer> fmt::Pointer for Pin<Ptr> {
1706 fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1707 fmt::Pointer::fmt(&self.__pointer, f)
1708 }
1709}
1710
1711// Note: this means that any impl of `CoerceUnsized` that allows coercing from
1712// a type that impls `Deref<Target=impl !Unpin>` to a type that impls
1713// `Deref<Target=Unpin>` is unsound. Any such impl would probably be unsound
1714// for other reasons, though, so we just need to take care not to allow such
1715// impls to land in std.
1716#[stable(feature = "pin", since = "1.33.0")]
1717impl<Ptr, U> CoerceUnsized<Pin<U>> for Pin<Ptr> where Ptr: CoerceUnsized<U> {}
1718
1719#[stable(feature = "pin", since = "1.33.0")]
1720impl<Ptr, U> DispatchFromDyn<Pin<U>> for Pin<Ptr> where Ptr: DispatchFromDyn<U> {}
1721
1722/// Constructs a <code>[Pin]<[&mut] T></code>, by pinning a `value: T` locally.
1723///
1724/// Unlike [`Box::pin`], this does not create a new heap allocation. As explained
1725/// below, the element might still end up on the heap however.
1726///
1727/// The local pinning performed by this macro is usually dubbed "stack"-pinning.
1728/// Outside of `async` contexts locals do indeed get stored on the stack. In
1729/// `async` functions or blocks however, any locals crossing an `.await` point
1730/// are part of the state captured by the `Future`, and will use the storage of
1731/// those. That storage can either be on the heap or on the stack. Therefore,
1732/// local pinning is a more accurate term.
1733///
1734/// If the type of the given value does not implement [`Unpin`], then this macro
1735/// pins the value in memory in a way that prevents moves. On the other hand,
1736/// if the type does implement [`Unpin`], <code>[Pin]<[&mut] T></code> behaves
1737/// like <code>[&mut] T</code>, and operations such as
1738/// [`mem::replace()`][crate::mem::replace] or [`mem::take()`](crate::mem::take)
1739/// will allow moves of the value.
1740/// See [the `Unpin` section of the `pin` module][self#unpin] for details.
1741///
1742/// ## Examples
1743///
1744/// ### Basic usage
1745///
1746/// ```rust
1747/// # use core::marker::PhantomPinned as Foo;
1748/// use core::pin::{pin, Pin};
1749///
1750/// fn stuff(foo: Pin<&mut Foo>) {
1751/// // …
1752/// # let _ = foo;
1753/// }
1754///
1755/// let pinned_foo = pin!(Foo { /* … */ });
1756/// stuff(pinned_foo);
1757/// // or, directly:
1758/// stuff(pin!(Foo { /* … */ }));
1759/// ```
1760///
1761/// ### Manually polling a `Future` (without `Unpin` bounds)
1762///
1763/// ```rust
1764/// use std::{
1765/// future::Future,
1766/// pin::pin,
1767/// task::{Context, Poll},
1768/// thread,
1769/// };
1770/// # use std::{sync::Arc, task::Wake, thread::Thread};
1771///
1772/// # /// A waker that wakes up the current thread when called.
1773/// # struct ThreadWaker(Thread);
1774/// #
1775/// # impl Wake for ThreadWaker {
1776/// # fn wake(self: Arc<Self>) {
1777/// # self.0.unpark();
1778/// # }
1779/// # }
1780/// #
1781/// /// Runs a future to completion.
1782/// fn block_on<Fut: Future>(fut: Fut) -> Fut::Output {
1783/// let waker_that_unparks_thread = // …
1784/// # Arc::new(ThreadWaker(thread::current())).into();
1785/// let mut cx = Context::from_waker(&waker_that_unparks_thread);
1786/// // Pin the future so it can be polled.
1787/// let mut pinned_fut = pin!(fut);
1788/// loop {
1789/// match pinned_fut.as_mut().poll(&mut cx) {
1790/// Poll::Pending => thread::park(),
1791/// Poll::Ready(res) => return res,
1792/// }
1793/// }
1794/// }
1795/// #
1796/// # assert_eq!(42, block_on(async { 42 }));
1797/// ```
1798///
1799/// ### With `Coroutine`s
1800///
1801/// ```rust
1802/// #![feature(coroutines)]
1803/// #![feature(coroutine_trait)]
1804/// use core::{
1805/// ops::{Coroutine, CoroutineState},
1806/// pin::pin,
1807/// };
1808///
1809/// fn coroutine_fn() -> impl Coroutine<Yield = usize, Return = ()> /* not Unpin */ {
1810/// // Allow coroutine to be self-referential (not `Unpin`)
1811/// // vvvvvv so that locals can cross yield points.
1812/// static || {
1813/// let foo = String::from("foo");
1814/// let foo_ref = &foo; // ------+
1815/// yield 0; // | <- crosses yield point!
1816/// println!("{foo_ref}"); // <--+
1817/// yield foo.len();
1818/// }
1819/// }
1820///
1821/// fn main() {
1822/// let mut coroutine = pin!(coroutine_fn());
1823/// match coroutine.as_mut().resume(()) {
1824/// CoroutineState::Yielded(0) => {},
1825/// _ => unreachable!(),
1826/// }
1827/// match coroutine.as_mut().resume(()) {
1828/// CoroutineState::Yielded(3) => {},
1829/// _ => unreachable!(),
1830/// }
1831/// match coroutine.resume(()) {
1832/// CoroutineState::Yielded(_) => unreachable!(),
1833/// CoroutineState::Complete(()) => {},
1834/// }
1835/// }
1836/// ```
1837///
1838/// ## Remarks
1839///
1840/// Precisely because a value is pinned to local storage, the resulting <code>[Pin]<[&mut] T></code>
1841/// reference ends up borrowing a local tied to that block: it can't escape it.
1842///
1843/// The following, for instance, fails to compile:
1844///
1845/// ```rust,compile_fail
1846/// use core::pin::{pin, Pin};
1847/// # use core::{marker::PhantomPinned as Foo, mem::drop as stuff};
1848///
1849/// let x: Pin<&mut Foo> = {
1850/// let x: Pin<&mut Foo> = pin!(Foo { /* … */ });
1851/// x
1852/// }; // <- Foo is dropped
1853/// stuff(x); // Error: use of dropped value
1854/// ```
1855///
1856/// <details><summary>Error message</summary>
1857///
1858/// ```console
1859/// error[E0716]: temporary value dropped while borrowed
1860/// --> src/main.rs:9:28
1861/// |
1862/// 8 | let x: Pin<&mut Foo> = {
1863/// | - borrow later stored here
1864/// 9 | let x: Pin<&mut Foo> = pin!(Foo { /* … */ });
1865/// | ^^^^^^^^^^^^^^^^^^^^^ creates a temporary value which is freed while still in use
1866/// 10 | x
1867/// 11 | }; // <- Foo is dropped
1868/// | - temporary value is freed at the end of this statement
1869/// |
1870/// = note: consider using a `let` binding to create a longer lived value
1871/// ```
1872///
1873/// </details>
1874///
1875/// This makes [`pin!`] **unsuitable to pin values when intending to _return_ them**. Instead, the
1876/// value is expected to be passed around _unpinned_ until the point where it is to be consumed,
1877/// where it is then useful and even sensible to pin the value locally using [`pin!`].
1878///
1879/// If you really need to return a pinned value, consider using [`Box::pin`] instead.
1880///
1881/// On the other hand, local pinning using [`pin!`] is likely to be cheaper than
1882/// pinning into a fresh heap allocation using [`Box::pin`]. Moreover, by virtue of not
1883/// requiring an allocator, [`pin!`] is the main non-`unsafe` `#![no_std]`-compatible [`Pin`]
1884/// constructor.
1885///
1886/// [`Box::pin`]: ../../std/boxed/struct.Box.html#method.pin
1887#[stable(feature = "pin_macro", since = "1.68.0")]
1888#[rustc_macro_transparency = "semitransparent"]
1889#[allow_internal_unstable(unsafe_pin_internals)]
1890pub macro pin($value:expr $(,)?) {
1891 // This is `Pin::new_unchecked(&mut { $value })`, so, for starters, let's
1892 // review such a hypothetical macro (that any user-code could define):
1893 //
1894 // ```rust
1895 // macro_rules! pin {( $value:expr ) => (
1896 // match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block.
1897 // $crate::pin::Pin::<&mut _>::new_unchecked(at_value)
1898 // }}
1899 // )}
1900 // ```
1901 //
1902 // Safety:
1903 // - `type P = &mut _`. There are thus no pathological `Deref{,Mut}` impls
1904 // that would break `Pin`'s invariants.
1905 // - `{ $value }` is braced, making it a _block expression_, thus **moving**
1906 // the given `$value`, and making it _become an **anonymous** temporary_.
1907 // By virtue of being anonymous, it can no longer be accessed, thus
1908 // preventing any attempts to `mem::replace` it or `mem::forget` it, _etc._
1909 //
1910 // This gives us a `pin!` definition that is sound, and which works, but only
1911 // in certain scenarios:
1912 // - If the `pin!(value)` expression is _directly_ fed to a function call:
1913 // `let poll = pin!(fut).poll(cx);`
1914 // - If the `pin!(value)` expression is part of a scrutinee:
1915 // ```rust
1916 // match pin!(fut) { pinned_fut => {
1917 // pinned_fut.as_mut().poll(...);
1918 // pinned_fut.as_mut().poll(...);
1919 // }} // <- `fut` is dropped here.
1920 // ```
1921 // Alas, it doesn't work for the more straight-forward use-case: `let` bindings.
1922 // ```rust
1923 // let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement
1924 // pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed
1925 // // note: consider using a `let` binding to create a longer lived value
1926 // ```
1927 // - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66
1928 //
1929 // This makes such a macro incredibly unergonomic in practice, and the reason most macros
1930 // out there had to take the path of being a statement/binding macro (_e.g._, `pin!(future);`)
1931 // instead of featuring the more intuitive ergonomics of an expression macro.
1932 //
1933 // Luckily, there is a way to avoid the problem. Indeed, the problem stems from the fact that a
1934 // temporary is dropped at the end of its enclosing statement when it is part of the parameters
1935 // given to function call, which has precisely been the case with our `Pin::new_unchecked()`!
1936 // For instance,
1937 // ```rust
1938 // let p = Pin::new_unchecked(&mut <temporary>);
1939 // ```
1940 // becomes:
1941 // ```rust
1942 // let p = { let mut anon = <temporary>; &mut anon };
1943 // ```
1944 //
1945 // However, when using a literal braced struct to construct the value, references to temporaries
1946 // can then be taken. This makes Rust change the lifespan of such temporaries so that they are,
1947 // instead, dropped _at the end of the enscoping block_.
1948 // For instance,
1949 // ```rust
1950 // let p = Pin { __pointer: &mut <temporary> };
1951 // ```
1952 // becomes:
1953 // ```rust
1954 // let mut anon = <temporary>;
1955 // let p = Pin { __pointer: &mut anon };
1956 // ```
1957 // which is *exactly* what we want.
1958 //
1959 // See https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension
1960 // for more info.
1961 $crate::pin::Pin::<&mut _> { __pointer: &mut { $value } }
1962}
1963