pin.rs - source
Description: Source of the Rust file `library/core/src/pin.rs`.

#
core/
pin.rs

    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], once a value is pinned,
    16//! it is necessarily valid at its memory location until the end of its lifespan. This concept
    17//! of "pinning" is necessary to implement safe interfaces on top of things like self-referential
    18//! types and intrusive data structures which cannot currently be modeled in fully safe Rust using
    19//! only 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-referential 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 are a few ways one might
    160//! be 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-referential 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 reasons 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 example, the implications of composing together the [`Future`]s which
    190//! will eventually 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 address-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 you really need to pin a value of a foreign or built-in type that implements [`Unpin`],
    377//! you'll need to create your own wrapper type around the [`Unpin`] type you want to pin and then
    378//! opt-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 <code>InnerT: [Unpin]</code> would allow safe code to
    383//! trivially move the inner value out of that pinning pointer, which is precisely what you're
    384//! seeking to prevent! Exposing a field of a pinned value through a pinning pointer is called
    385//! "projecting" a pin, and the more general case of deciding in which cases a pin should be able
    386//! to be 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//!     /// Creates 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 requires some care, 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 library 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
    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::hash::{Hash, Hasher};
    924use crate::ops::{CoerceUnsized, Deref, DerefMut, DerefPure, DispatchFromDyn, LegacyReceiver};
    925#[allow(unused_imports)]
    926use crate::{
    927    cell::{RefCell, UnsafeCell},
    928    future::Future,
    929    marker::PhantomPinned,
    930    mem, ptr,
    931};
    932use crate::{cmp, fmt};
    933
    934mod unsafe_pinned;
    935
    936#[unstable(feature = "unsafe_pinned", issue = "125735")]
    937pub use self::unsafe_pinned::UnsafePinned;
    938
    939/// A pointer which pins its pointee in place.
    940///
    941/// [`Pin`] is a wrapper around some kind of pointer `Ptr` which makes that pointer "pin" its
    942/// pointee value in place, thus preventing the value referenced by that pointer from being moved
    943/// or otherwise invalidated at that place in memory unless it implements [`Unpin`].
    944///
    945/// *See the [`pin` module] documentation for a more thorough exploration of pinning.*
    946///
    947/// ## Pinning values with [`Pin<Ptr>`]
    948///
    949/// In order to pin a value, we wrap a *pointer to that value* (of some type `Ptr`) in a
    950/// [`Pin<Ptr>`]. [`Pin<Ptr>`] can wrap any pointer type, forming a promise that the **pointee**
    951/// will not be *moved* or [otherwise invalidated][subtle-details]. If the pointee value's type
    952/// implements [`Unpin`], we are free to disregard these requirements entirely and can wrap any
    953/// pointer to that value in [`Pin`] directly via [`Pin::new`]. If the pointee value's type does
    954/// not implement [`Unpin`], then Rust will not let us use the [`Pin::new`] function directly and
    955/// we'll need to construct a [`Pin`]-wrapped pointer in one of the more specialized manners
    956/// discussed below.
    957///
    958/// We call such a [`Pin`]-wrapped pointer a **pinning pointer** (or pinning ref, or pinning
    959/// [`Box`], etc.) because its existence is the thing that is pinning the underlying pointee in
    960/// place: it is the metaphorical "pin" securing the data in place on the pinboard (in memory).
    961///
    962/// It is important to stress that the thing in the [`Pin`] is not the value which we want to pin
    963/// itself, but rather a pointer to that value! A [`Pin<Ptr>`] does not pin the `Ptr` but rather
    964/// the pointer's ***pointee** value*.
    965///
    966/// The most common set of types which require pinning related guarantees for soundness are the
    967/// compiler-generated state machines that implement [`Future`] for the return value of
    968/// `async fn`s. These compiler-generated [`Future`]s may contain self-referential pointers, one
    969/// of the most common use cases for [`Pin`]. More details on this point are provided in the
    970/// [`pin` module] docs, but suffice it to say they require the guarantees provided by pinning to
    971/// be implemented soundly.
    972///
    973/// This requirement for the implementation of `async fn`s means that the [`Future`] trait
    974/// requires all calls to [`poll`] to use a <code>self: [Pin]\<&mut Self></code> parameter instead
    975/// of the usual `&mut self`. Therefore, when manually polling a future, you will need to pin it
    976/// first.
    977///
    978/// You may notice that `async fn`-sourced [`Future`]s are only a small percentage of all
    979/// [`Future`]s that exist, yet we had to modify the signature of [`poll`] for all [`Future`]s
    980/// to accommodate them. This is unfortunate, but there is a way that the language attempts to
    981/// alleviate the extra friction that this API choice incurs: the [`Unpin`] trait.
    982///
    983/// The vast majority of Rust types have no reason to ever care about being pinned. These
    984/// types implement the [`Unpin`] trait, which entirely opts all values of that type out of
    985/// pinning-related guarantees. For values of these types, pinning a value by pointing to it with a
    986/// [`Pin<Ptr>`] will have no actual effect.
    987///
    988/// The reason this distinction exists is exactly to allow APIs like [`Future::poll`] to take a
    989/// [`Pin<Ptr>`] as an argument for all types while only forcing [`Future`] types that actually
    990/// care about pinning guarantees pay the ergonomics cost. For the majority of [`Future`] types
    991/// that don't have a reason to care about being pinned and therefore implement [`Unpin`], the
    992/// <code>[Pin]\<&mut Self></code> will act exactly like a regular `&mut Self`, allowing direct
    993/// access to the underlying value. Only types that *don't* implement [`Unpin`] will be restricted.
    994///
    995/// ### Pinning a value of a type that implements [`Unpin`]
    996///
    997/// If the type of the value you need to "pin" implements [`Unpin`], you can trivially wrap any
    998/// pointer to that value in a [`Pin`] by calling [`Pin::new`].
    999///
    1000/// ```
    1001/// use std::pin::Pin;
    1002///
    1003/// // Create a value of a type that implements `Unpin`
    1004/// let mut unpin_future = std::future::ready(5);
    1005///
    1006/// // Pin it by creating a pinning mutable reference to it (ready to be `poll`ed!)
    1007/// let my_pinned_unpin_future: Pin<&mut _> = Pin::new(&mut unpin_future);
    1008/// ```
    1009///
    1010/// ### Pinning a value inside a [`Box`]
    1011///
    1012/// The simplest and most flexible way to pin a value that does not implement [`Unpin`] is to put
    1013/// that value inside a [`Box`] and then turn that [`Box`] into a "pinning [`Box`]" by wrapping it
    1014/// in a [`Pin`]. You can do both of these in a single step using [`Box::pin`]. Let's see an
    1015/// example of using this flow to pin a [`Future`] returned from calling an `async fn`, a common
    1016/// use case as described above.
    1017///
    1018/// ```
    1019/// use std::pin::Pin;
    1020///
    1021/// async fn add_one(x: u32) -> u32 {
    1022///     x + 1
    1023/// }
    1024///
    1025/// // Call the async function to get a future back
    1026/// let fut = add_one(42);
    1027///
    1028/// // Pin the future inside a pinning box
    1029/// let pinned_fut: Pin<Box<_>> = Box::pin(fut);
    1030/// ```
    1031///
    1032/// If you have a value which is already boxed, for example a [`Box<dyn Future>`][Box], you can pin
    1033/// that value in-place at its current memory address using [`Box::into_pin`].
    1034///
    1035/// ```
    1036/// use std::pin::Pin;
    1037/// use std::future::Future;
    1038///
    1039/// async fn add_one(x: u32) -> u32 {
    1040///     x + 1
    1041/// }
    1042///
    1043/// fn boxed_add_one(x: u32) -> Box<dyn Future<Output = u32>> {
    1044///     Box::new(add_one(x))
    1045/// }
    1046///
    1047/// let boxed_fut = boxed_add_one(42);
    1048///
    1049/// // Pin the future inside the existing box
    1050/// let pinned_fut: Pin<Box<_>> = Box::into_pin(boxed_fut);
    1051/// ```
    1052///
    1053/// There are similar pinning methods offered on the other standard library smart pointer types
    1054/// as well, like [`Rc`] and [`Arc`].
    1055///
    1056/// ### Pinning a value on the stack using [`pin!`]
    1057///
    1058/// There are some situations where it is desirable or even required (for example, in a `#[no_std]`
    1059/// context where you don't have access to the standard library or allocation in general) to
    1060/// pin a value which does not implement [`Unpin`] to its location on the stack. Doing so is
    1061/// possible using the [`pin!`] macro. See its documentation for more.
    1062///
    1063/// ## Layout and ABI
    1064///
    1065/// [`Pin<Ptr>`] is guaranteed to have the same memory layout and ABI[^noalias] as `Ptr`.
    1066///
    1067/// [^noalias]: There is a bit of nuance here that is still being decided about whether the
    1068/// aliasing semantics of `Pin<&mut T>` should be different than `&mut T`, but this is true as of
    1069/// today.
    1070///
    1071/// [`pin!`]: crate::pin::pin "pin!"
    1072/// [`Future`]: crate::future::Future "Future"
    1073/// [`poll`]: crate::future::Future::poll "Future::poll"
    1074/// [`Future::poll`]: crate::future::Future::poll "Future::poll"
    1075/// [`pin` module]: self "pin module"
    1076/// [`Rc`]: ../../std/rc/struct.Rc.html "Rc"
    1077/// [`Arc`]: ../../std/sync/struct.Arc.html "Arc"
    1078/// [Box]: ../../std/boxed/struct.Box.html "Box"
    1079/// [`Box`]: ../../std/boxed/struct.Box.html "Box"
    1080/// [`Box::pin`]: ../../std/boxed/struct.Box.html#method.pin "Box::pin"
    1081/// [`Box::into_pin`]: ../../std/boxed/struct.Box.html#method.into_pin "Box::into_pin"
    1082/// [subtle-details]: self#subtle-details-and-the-drop-guarantee "pin subtle details"
    1083/// [`unsafe`]: ../../std/keyword.unsafe.html "keyword unsafe"
    1084//
    1085// Note: the `Clone` derive below causes unsoundness as it's possible to implement
    1086// `Clone` for mutable references.
    1087// See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311> for more details.
    1088#[stable(feature = "pin", since = "1.33.0")]
    1089#[lang = "pin"]
    1090#[fundamental]
    1091#[repr(transparent)]
    1092#[rustc_pub_transparent]
    1093#[derive(Copy, Clone)]
    1094pub struct Pin<Ptr> {
    1095    pointer: Ptr,
    1096}
    1097
    1098// The following implementations aren't derived in order to avoid soundness
    1099// issues. `&self.pointer` should not be accessible to untrusted trait
    1100// implementations.
    1101//
    1102// See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73> for more details.
    1103
    1104#[stable(feature = "pin_trait_impls", since = "1.41.0")]
    1105impl<Ptr: Deref, Q: Deref> PartialEq<Pin<Q>> for Pin<Ptr>
    1106where
    1107    Ptr::Target: PartialEq<Q::Target>,
    1108{
    1109    fn eq(&self, other: &Pin<Q>) -> bool {
    1110        Ptr::Target::eq(self, other)
    1111    }
    1112
    1113    fn ne(&self, other: &Pin<Q>) -> bool {
    1114        Ptr::Target::ne(self, other)
    1115    }
    1116}
    1117
    1118#[stable(feature = "pin_trait_impls", since = "1.41.0")]
    1119impl<Ptr: Deref<Target: Eq>> Eq for Pin<Ptr> {}
    1120
    1121#[stable(feature = "pin_trait_impls", since = "1.41.0")]
    1122impl<Ptr: Deref, Q: Deref> PartialOrd<Pin<Q>> for Pin<Ptr>
    1123where
    1124    Ptr::Target: PartialOrd<Q::Target>,
    1125{
    1126    fn partial_cmp(&self, other: &Pin<Q>) -> Option<cmp::Ordering> {
    1127        Ptr::Target::partial_cmp(self, other)
    1128    }
    1129
    1130    fn lt(&self, other: &Pin<Q>) -> bool {
    1131        Ptr::Target::lt(self, other)
    1132    }
    1133
    1134    fn le(&self, other: &Pin<Q>) -> bool {
    1135        Ptr::Target::le(self, other)
    1136    }
    1137
    1138    fn gt(&self, other: &Pin<Q>) -> bool {
    1139        Ptr::Target::gt(self, other)
    1140    }
    1141
    1142    fn ge(&self, other: &Pin<Q>) -> bool {
    1143        Ptr::Target::ge(self, other)
    1144    }
    1145}
    1146
    1147#[stable(feature = "pin_trait_impls", since = "1.41.0")]
    1148impl<Ptr: Deref<Target: Ord>> Ord for Pin<Ptr> {
    1149    fn cmp(&self, other: &Self) -> cmp::Ordering {
    1150        Ptr::Target::cmp(self, other)
    1151    }
    1152}
    1153
    1154#[stable(feature = "pin_trait_impls", since = "1.41.0")]
    1155impl<Ptr: Deref<Target: Hash>> Hash for Pin<Ptr> {
    1156    fn hash<H: Hasher>(&self, state: &mut H) {
    1157        Ptr::Target::hash(self, state);
    1158    }
    1159}
    1160
    1161impl<Ptr: Deref<Target: Unpin>> Pin<Ptr> {
    1162    /// Constructs a new `Pin<Ptr>` around a pointer to some data of a type that
    1163    /// implements [`Unpin`].
    1164    ///
    1165    /// Unlike `Pin::new_unchecked`, this method is safe because the pointer
    1166    /// `Ptr` dereferences to an [`Unpin`] type, which cancels the pinning guarantees.
    1167    ///
    1168    /// # Examples
    1169    ///
    1170    /// ```
    1171    /// use std::pin::Pin;
    1172    ///
    1173    /// let mut val: u8 = 5;
    1174    ///
    1175    /// // Since `val` doesn't care about being moved, we can safely create a "facade" `Pin`
    1176    /// // which will allow `val` to participate in `Pin`-bound apis  without checking that
    1177    /// // pinning guarantees are actually upheld.
    1178    /// let mut pinned: Pin<&mut u8> = Pin::new(&mut val);
    1179    /// ```
    1180    #[inline(always)]
    1181    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1182    #[stable(feature = "pin", since = "1.33.0")]
    1183    pub const fn new(pointer: Ptr) -> Pin<Ptr> {
    1184        // SAFETY: the value pointed to is `Unpin`, and so has no requirements
    1185        // around pinning.
    1186        unsafe { Pin::new_unchecked(pointer) }
    1187    }
    1188
    1189    /// Unwraps this `Pin<Ptr>`, returning the underlying pointer.
    1190    ///
    1191    /// Doing this operation safely requires that the data pointed at by this pinning pointer
    1192    /// implements [`Unpin`] so that we can ignore the pinning invariants when unwrapping it.
    1193    ///
    1194    /// # Examples
    1195    ///
    1196    /// ```
    1197    /// use std::pin::Pin;
    1198    ///
    1199    /// let mut val: u8 = 5;
    1200    /// let pinned: Pin<&mut u8> = Pin::new(&mut val);
    1201    ///
    1202    /// // Unwrap the pin to get the underlying mutable reference to the value. We can do
    1203    /// // this because `val` doesn't care about being moved, so the `Pin` was just
    1204    /// // a "facade" anyway.
    1205    /// let r = Pin::into_inner(pinned);
    1206    /// assert_eq!(*r, 5);
    1207    /// ```
    1208    #[inline(always)]
    1209    #[rustc_allow_const_fn_unstable(const_precise_live_drops)]
    1210    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1211    #[stable(feature = "pin_into_inner", since = "1.39.0")]
    1212    pub const fn into_inner(pin: Pin<Ptr>) -> Ptr {
    1213        pin.pointer
    1214    }
    1215}
    1216
    1217impl<Ptr: Deref> Pin<Ptr> {
    1218    /// Constructs a new `Pin<Ptr>` around a reference to some data of a type that
    1219    /// may or may not implement [`Unpin`].
    1220    ///
    1221    /// If `pointer` dereferences to an [`Unpin`] type, [`Pin::new`] should be used
    1222    /// instead.
    1223    ///
    1224    /// # Safety
    1225    ///
    1226    /// This constructor is unsafe because we cannot guarantee that the data
    1227    /// pointed to by `pointer` is pinned. At its core, pinning a value means making the
    1228    /// guarantee that the value's data will not be moved nor have its storage invalidated until
    1229    /// it gets dropped. For a more thorough explanation of pinning, see the [`pin` module docs].
    1230    ///
    1231    /// If the caller that is constructing this `Pin<Ptr>` does not ensure that the data `Ptr`
    1232    /// points to is pinned, that is a violation of the API contract and may lead to undefined
    1233    /// behavior in later (even safe) operations.
    1234    ///
    1235    /// By using this method, you are also making a promise about the [`Deref`],
    1236    /// [`DerefMut`], and [`Drop`] implementations of `Ptr`, if they exist. Most importantly, they
    1237    /// must not move out of their `self` arguments: `Pin::as_mut` and `Pin::as_ref`
    1238    /// will call `DerefMut::deref_mut` and `Deref::deref` *on the pointer type `Ptr`*
    1239    /// and expect these methods to uphold the pinning invariants.
    1240    /// Moreover, by calling this method you promise that the reference `Ptr`
    1241    /// dereferences to will not be moved out of again; in particular, it
    1242    /// must not be possible to obtain a `&mut Ptr::Target` and then
    1243    /// move out of that reference (using, for example [`mem::swap`]).
    1244    ///
    1245    /// For example, calling `Pin::new_unchecked` on an `&'a mut T` is unsafe because
    1246    /// while you are able to pin it for the given lifetime `'a`, you have no control
    1247    /// over whether it is kept pinned once `'a` ends, and therefore cannot uphold the
    1248    /// guarantee that a value, once pinned, remains pinned until it is dropped:
    1249    ///
    1250    /// ```
    1251    /// use std::mem;
    1252    /// use std::pin::Pin;
    1253    ///
    1254    /// fn move_pinned_ref<T>(mut a: T, mut b: T) {
    1255    ///     unsafe {
    1256    ///         let p: Pin<&mut T> = Pin::new_unchecked(&mut a);
    1257    ///         // This should mean the pointee `a` can never move again.
    1258    ///     }
    1259    ///     mem::swap(&mut a, &mut b); // Potential UB down the road ⚠️
    1260    ///     // The address of `a` changed to `b`'s stack slot, so `a` got moved even
    1261    ///     // though we have previously pinned it! We have violated the pinning API contract.
    1262    /// }
    1263    /// ```
    1264    /// A value, once pinned, must remain pinned until it is dropped (unless its type implements
    1265    /// `Unpin`). Because `Pin<&mut T>` does not own the value, dropping the `Pin` will not drop
    1266    /// the value and will not end the pinning contract. So moving the value after dropping the
    1267    /// `Pin<&mut T>` is still a violation of the API contract.
    1268    ///
    1269    /// Similarly, calling `Pin::new_unchecked` on an `Rc<T>` is unsafe because there could be
    1270    /// aliases to the same data that are not subject to the pinning restrictions:
    1271    /// ```
    1272    /// use std::rc::Rc;
    1273    /// use std::pin::Pin;
    1274    ///
    1275    /// fn move_pinned_rc<T>(mut x: Rc<T>) {
    1276    ///     // This should mean the pointee can never move again.
    1277    ///     let pin = unsafe { Pin::new_unchecked(Rc::clone(&x)) };
    1278    ///     {
    1279    ///         let p: Pin<&T> = pin.as_ref();
    1280    ///         // ...
    1281    ///     }
    1282    ///     drop(pin);
    1283    ///
    1284    ///     let content = Rc::get_mut(&mut x).unwrap(); // Potential UB down the road ⚠️
    1285    ///     // Now, if `x` was the only reference, we have a mutable reference to
    1286    ///     // data that we pinned above, which we could use to move it as we have
    1287    ///     // seen in the previous example. We have violated the pinning API contract.
    1288    /// }
    1289    /// ```
    1290    ///
    1291    /// ## Pinning of closure captures
    1292    ///
    1293    /// Particular care is required when using `Pin::new_unchecked` in a closure:
    1294    /// `Pin::new_unchecked(&mut var)` where `var` is a by-value (moved) closure capture
    1295    /// implicitly makes the promise that the closure itself is pinned, and that *all* uses
    1296    /// of this closure capture respect that pinning.
    1297    /// ```
    1298    /// use std::pin::Pin;
    1299    /// use std::task::Context;
    1300    /// use std::future::Future;
    1301    ///
    1302    /// fn move_pinned_closure(mut x: impl Future, cx: &mut Context<'_>) {
    1303    ///     // Create a closure that moves `x`, and then internally uses it in a pinned way.
    1304    ///     let mut closure = move || unsafe {
    1305    ///         let _ignore = Pin::new_unchecked(&mut x).poll(cx);
    1306    ///     };
    1307    ///     // Call the closure, so the future can assume it has been pinned.
    1308    ///     closure();
    1309    ///     // Move the closure somewhere else. This also moves `x`!
    1310    ///     let mut moved = closure;
    1311    ///     // Calling it again means we polled the future from two different locations,
    1312    ///     // violating the pinning API contract.
    1313    ///     moved(); // Potential UB ⚠️
    1314    /// }
    1315    /// ```
    1316    /// When passing a closure to another API, it might be moving the closure any time, so
    1317    /// `Pin::new_unchecked` on closure captures may only be used if the API explicitly documents
    1318    /// that the closure is pinned.
    1319    ///
    1320    /// The better alternative is to avoid all that trouble and do the pinning in the outer function
    1321    /// instead (here using the [`pin!`][crate::pin::pin] macro):
    1322    /// ```
    1323    /// use std::pin::pin;
    1324    /// use std::task::Context;
    1325    /// use std::future::Future;
    1326    ///
    1327    /// fn move_pinned_closure(mut x: impl Future, cx: &mut Context<'_>) {
    1328    ///     let mut x = pin!(x);
    1329    ///     // Create a closure that captures `x: Pin<&mut _>`, which is safe to move.
    1330    ///     let mut closure = move || {
    1331    ///         let _ignore = x.as_mut().poll(cx);
    1332    ///     };
    1333    ///     // Call the closure, so the future can assume it has been pinned.
    1334    ///     closure();
    1335    ///     // Move the closure somewhere else.
    1336    ///     let mut moved = closure;
    1337    ///     // Calling it again here is fine (except that we might be polling a future that already
    1338    ///     // returned `Poll::Ready`, but that is a separate problem).
    1339    ///     moved();
    1340    /// }
    1341    /// ```
    1342    ///
    1343    /// [`mem::swap`]: crate::mem::swap
    1344    /// [`pin` module docs]: self
    1345    #[lang = "new_unchecked"]
    1346    #[inline(always)]
    1347    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1348    #[stable(feature = "pin", since = "1.33.0")]
    1349    pub const unsafe fn new_unchecked(pointer: Ptr) -> Pin<Ptr> {
    1350        Pin { pointer }
    1351    }
    1352
    1353    /// Gets a shared reference to the pinned value this [`Pin`] points to.
    1354    ///
    1355    /// This is a generic method to go from `&Pin<Pointer<T>>` to `Pin<&T>`.
    1356    /// It is safe because, as part of the contract of `Pin::new_unchecked`,
    1357    /// the pointee cannot move after `Pin<Pointer<T>>` got created.
    1358    /// "Malicious" implementations of `Pointer::Deref` are likewise
    1359    /// ruled out by the contract of `Pin::new_unchecked`.
    1360    #[stable(feature = "pin", since = "1.33.0")]
    1361    #[inline(always)]
    1362    #[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1363    pub const fn as_ref(&self) -> Pin<&Ptr::Target>
    1364    where
    1365        Ptr: [const] Deref,
    1366    {
    1367        // SAFETY: see documentation on this function
    1368        unsafe { Pin::new_unchecked(&*self.pointer) }
    1369    }
    1370}
    1371
    1372// These methods being in a `Ptr: DerefMut` impl block concerns semver stability.
    1373// Currently, calling e.g. `.set()` on a `Pin<&T>` sees that `Ptr: DerefMut`
    1374// doesn't hold, and goes to check for a `.set()` method on `T`. But, if the
    1375// `where Ptr: DerefMut` bound is moved to the method, rustc sees the impl block
    1376// as a valid candidate, and doesn't go on to check other candidates when it
    1377// sees that the bound on the method.
    1378impl<Ptr: DerefMut> Pin<Ptr> {
    1379    /// Gets a mutable reference to the pinned value this `Pin<Ptr>` points to.
    1380    ///
    1381    /// This is a generic method to go from `&mut Pin<Pointer<T>>` to `Pin<&mut T>`.
    1382    /// It is safe because, as part of the contract of `Pin::new_unchecked`,
    1383    /// the pointee cannot move after `Pin<Pointer<T>>` got created.
    1384    /// "Malicious" implementations of `Pointer::DerefMut` are likewise
    1385    /// ruled out by the contract of `Pin::new_unchecked`.
    1386    ///
    1387    /// This method is useful when doing multiple calls to functions that consume the
    1388    /// pinning pointer.
    1389    ///
    1390    /// # Example
    1391    ///
    1392    /// ```
    1393    /// use std::pin::Pin;
    1394    ///
    1395    /// # struct Type {}
    1396    /// impl Type {
    1397    ///     fn method(self: Pin<&mut Self>) {
    1398    ///         // do something
    1399    ///     }
    1400    ///
    1401    ///     fn call_method_twice(mut self: Pin<&mut Self>) {
    1402    ///         // `method` consumes `self`, so reborrow the `Pin<&mut Self>` via `as_mut`.
    1403    ///         self.as_mut().method();
    1404    ///         self.as_mut().method();
    1405    ///     }
    1406    /// }
    1407    /// ```
    1408    #[stable(feature = "pin", since = "1.33.0")]
    1409    #[inline(always)]
    1410    #[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1411    pub const fn as_mut(&mut self) -> Pin<&mut Ptr::Target>
    1412    where
    1413        Ptr: [const] DerefMut,
    1414    {
    1415        // SAFETY: see documentation on this function
    1416        unsafe { Pin::new_unchecked(&mut *self.pointer) }
    1417    }
    1418
    1419    /// Gets `Pin<&mut T>` to the underlying pinned value from this nested `Pin`-pointer.
    1420    ///
    1421    /// This is a generic method to go from `Pin<&mut Pin<Pointer<T>>>` to `Pin<&mut T>`. It is
    1422    /// safe because the existence of a `Pin<Pointer<T>>` ensures that the pointee, `T`, cannot
    1423    /// move in the future, and this method does not enable the pointee to move. "Malicious"
    1424    /// implementations of `Ptr::DerefMut` are likewise ruled out by the contract of
    1425    /// `Pin::new_unchecked`.
    1426    #[stable(feature = "pin_deref_mut", since = "1.84.0")]
    1427    #[must_use = "`self` will be dropped if the result is not used"]
    1428    #[inline(always)]
    1429    #[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1430    pub const fn as_deref_mut(self: Pin<&mut Self>) -> Pin<&mut Ptr::Target>
    1431    where
    1432        Ptr: [const] DerefMut,
    1433    {
    1434        // SAFETY: What we're asserting here is that going from
    1435        //
    1436        //     Pin<&mut Pin<Ptr>>
    1437        //
    1438        // to
    1439        //
    1440        //     Pin<&mut Ptr::Target>
    1441        //
    1442        // is safe.
    1443        //
    1444        // We need to ensure that two things hold for that to be the case:
    1445        //
    1446        // 1) Once we give out a `Pin<&mut Ptr::Target>`, a `&mut Ptr::Target` will not be given out.
    1447        // 2) By giving out a `Pin<&mut Ptr::Target>`, we do not risk violating
    1448        // `Pin<&mut Pin<Ptr>>`
    1449        //
    1450        // The existence of `Pin<Ptr>` is sufficient to guarantee #1: since we already have a
    1451        // `Pin<Ptr>`, it must already uphold the pinning guarantees, which must mean that
    1452        // `Pin<&mut Ptr::Target>` does as well, since `Pin::as_mut` is safe. We do not have to rely
    1453        // on the fact that `Ptr` is _also_ pinned.
    1454        //
    1455        // For #2, we need to ensure that code given a `Pin<&mut Ptr::Target>` cannot cause the
    1456        // `Pin<Ptr>` to move? That is not possible, since `Pin<&mut Ptr::Target>` no longer retains
    1457        // any access to the `Ptr` itself, much less the `Pin<Ptr>`.
    1458        unsafe { self.get_unchecked_mut() }.as_mut()
    1459    }
    1460
    1461    /// Assigns a new value to the memory location pointed to by the `Pin<Ptr>`.
    1462    ///
    1463    /// This overwrites pinned data, but that is okay: the original pinned value's destructor gets
    1464    /// run before being overwritten and the new value is also a valid value of the same type, so
    1465    /// no pinning invariant is violated. See [the `pin` module documentation][subtle-details]
    1466    /// for more information on how this upholds the pinning invariants.
    1467    ///
    1468    /// # Example
    1469    ///
    1470    /// ```
    1471    /// use std::pin::Pin;
    1472    ///
    1473    /// let mut val: u8 = 5;
    1474    /// let mut pinned: Pin<&mut u8> = Pin::new(&mut val);
    1475    /// println!("{}", pinned); // 5
    1476    /// pinned.set(10);
    1477    /// println!("{}", pinned); // 10
    1478    /// ```
    1479    ///
    1480    /// [subtle-details]: self#subtle-details-and-the-drop-guarantee
    1481    #[stable(feature = "pin", since = "1.33.0")]
    1482    #[inline(always)]
    1483    pub fn set(&mut self, value: Ptr::Target)
    1484    where
    1485        Ptr::Target: Sized,
    1486    {
    1487        *(self.pointer) = value;
    1488    }
    1489}
    1490
    1491impl<Ptr: Deref> Pin<Ptr> {
    1492    /// Unwraps this `Pin<Ptr>`, returning the underlying `Ptr`.
    1493    ///
    1494    /// # Safety
    1495    ///
    1496    /// This function is unsafe. You must guarantee that you will continue to
    1497    /// treat the pointer `Ptr` as pinned after you call this function, so that
    1498    /// the invariants on the `Pin` type can be upheld. If the code using the
    1499    /// resulting `Ptr` does not continue to maintain the pinning invariants that
    1500    /// is a violation of the API contract and may lead to undefined behavior in
    1501    /// later (safe) operations.
    1502    ///
    1503    /// Note that you must be able to guarantee that the data pointed to by `Ptr`
    1504    /// will be treated as pinned all the way until its `drop` handler is complete!
    1505    ///
    1506    /// *For more information, see the [`pin` module docs][self]*
    1507    ///
    1508    /// If the underlying data is [`Unpin`], [`Pin::into_inner`] should be used
    1509    /// instead.
    1510    #[inline(always)]
    1511    #[rustc_allow_const_fn_unstable(const_precise_live_drops)]
    1512    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1513    #[stable(feature = "pin_into_inner", since = "1.39.0")]
    1514    pub const unsafe fn into_inner_unchecked(pin: Pin<Ptr>) -> Ptr {
    1515        pin.pointer
    1516    }
    1517}
    1518
    1519impl<'a, T: ?Sized> Pin<&'a T> {
    1520    /// Constructs a new pin by mapping the interior value.
    1521    ///
    1522    /// For example, if you wanted to get a `Pin` of a field of something,
    1523    /// you could use this to get access to that field in one line of code.
    1524    /// However, there are several gotchas with these "pinning projections";
    1525    /// see the [`pin` module] documentation for further details on that topic.
    1526    ///
    1527    /// # Safety
    1528    ///
    1529    /// This function is unsafe. You must guarantee that the data you return
    1530    /// will not move so long as the argument value does not move (for example,
    1531    /// because it is one of the fields of that value), and also that you do
    1532    /// not move out of the argument you receive to the interior function.
    1533    ///
    1534    /// [`pin` module]: self#projections-and-structural-pinning
    1535    #[stable(feature = "pin", since = "1.33.0")]
    1536    pub unsafe fn map_unchecked<U, F>(self, func: F) -> Pin<&'a U>
    1537    where
    1538        U: ?Sized,
    1539        F: FnOnce(&T) -> &U,
    1540    {
    1541        let pointer = &*self.pointer;
    1542        let new_pointer = func(pointer);
    1543
    1544        // SAFETY: the safety contract for `new_unchecked` must be
    1545        // upheld by the caller.
    1546        unsafe { Pin::new_unchecked(new_pointer) }
    1547    }
    1548
    1549    /// Gets a shared reference out of a pin.
    1550    ///
    1551    /// This is safe because it is not possible to move out of a shared reference.
    1552    /// It may seem like there is an issue here with interior mutability: in fact,
    1553    /// it *is* possible to move a `T` out of a `&RefCell<T>`. However, this is
    1554    /// not a problem as long as there does not also exist a `Pin<&T>` pointing
    1555    /// to the inner `T` inside the `RefCell`, and `RefCell<T>` does not let you get a
    1556    /// `Pin<&T>` pointer to its contents. See the discussion on ["pinning projections"]
    1557    /// for further details.
    1558    ///
    1559    /// Note: `Pin` also implements `Deref` to the target, which can be used
    1560    /// to access the inner value. However, `Deref` only provides a reference
    1561    /// that lives for as long as the borrow of the `Pin`, not the lifetime of
    1562    /// the reference contained in the `Pin`. This method allows turning the `Pin` into a reference
    1563    /// with the same lifetime as the reference it wraps.
    1564    ///
    1565    /// ["pinning projections"]: self#projections-and-structural-pinning
    1566    #[inline(always)]
    1567    #[must_use]
    1568    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1569    #[stable(feature = "pin", since = "1.33.0")]
    1570    pub const fn get_ref(self) -> &'a T {
    1571        self.pointer
    1572    }
    1573}
    1574
    1575impl<'a, T: ?Sized> Pin<&'a mut T> {
    1576    /// Converts this `Pin<&mut T>` into a `Pin<&T>` with the same lifetime.
    1577    #[inline(always)]
    1578    #[must_use = "`self` will be dropped if the result is not used"]
    1579    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1580    #[stable(feature = "pin", since = "1.33.0")]
    1581    pub const fn into_ref(self) -> Pin<&'a T> {
    1582        Pin { pointer: self.pointer }
    1583    }
    1584
    1585    /// Gets a mutable reference to the data inside of this `Pin`.
    1586    ///
    1587    /// This requires that the data inside this `Pin` is `Unpin`.
    1588    ///
    1589    /// Note: `Pin` also implements `DerefMut` to the data, which can be used
    1590    /// to access the inner value. However, `DerefMut` only provides a reference
    1591    /// that lives for as long as the borrow of the `Pin`, not the lifetime of
    1592    /// the `Pin` itself. This method allows turning the `Pin` into a reference
    1593    /// with the same lifetime as the original `Pin`.
    1594    #[inline(always)]
    1595    #[must_use = "`self` will be dropped if the result is not used"]
    1596    #[stable(feature = "pin", since = "1.33.0")]
    1597    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1598    pub const fn get_mut(self) -> &'a mut T
    1599    where
    1600        T: Unpin,
    1601    {
    1602        self.pointer
    1603    }
    1604
    1605    /// Gets a mutable reference to the data inside of this `Pin`.
    1606    ///
    1607    /// # Safety
    1608    ///
    1609    /// This function is unsafe. You must guarantee that you will never move
    1610    /// the data out of the mutable reference you receive when you call this
    1611    /// function, so that the invariants on the `Pin` type can be upheld.
    1612    ///
    1613    /// If the underlying data is `Unpin`, `Pin::get_mut` should be used
    1614    /// instead.
    1615    #[inline(always)]
    1616    #[must_use = "`self` will be dropped if the result is not used"]
    1617    #[stable(feature = "pin", since = "1.33.0")]
    1618    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1619    pub const unsafe fn get_unchecked_mut(self) -> &'a mut T {
    1620        self.pointer
    1621    }
    1622
    1623    /// Constructs a new pin by mapping the interior value.
    1624    ///
    1625    /// For example, if you wanted to get a `Pin` of a field of something,
    1626    /// you could use this to get access to that field in one line of code.
    1627    /// However, there are several gotchas with these "pinning projections";
    1628    /// see the [`pin` module] documentation for further details on that topic.
    1629    ///
    1630    /// # Safety
    1631    ///
    1632    /// This function is unsafe. You must guarantee that the data you return
    1633    /// will not move so long as the argument value does not move (for example,
    1634    /// because it is one of the fields of that value), and also that you do
    1635    /// not move out of the argument you receive to the interior function.
    1636    ///
    1637    /// [`pin` module]: self#projections-and-structural-pinning
    1638    #[must_use = "`self` will be dropped if the result is not used"]
    1639    #[stable(feature = "pin", since = "1.33.0")]
    1640    pub unsafe fn map_unchecked_mut<U, F>(self, func: F) -> Pin<&'a mut U>
    1641    where
    1642        U: ?Sized,
    1643        F: FnOnce(&mut T) -> &mut U,
    1644    {
    1645        // SAFETY: the caller is responsible for not moving the
    1646        // value out of this reference.
    1647        let pointer = unsafe { Pin::get_unchecked_mut(self) };
    1648        let new_pointer = func(pointer);
    1649        // SAFETY: as the value of `this` is guaranteed to not have
    1650        // been moved out, this call to `new_unchecked` is safe.
    1651        unsafe { Pin::new_unchecked(new_pointer) }
    1652    }
    1653}
    1654
    1655impl<T: ?Sized> Pin<&'static T> {
    1656    /// Gets a pinning reference from a `&'static` reference.
    1657    ///
    1658    /// This is safe because `T` is borrowed immutably for the `'static` lifetime, which
    1659    /// never ends.
    1660    #[stable(feature = "pin_static_ref", since = "1.61.0")]
    1661    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1662    pub const fn static_ref(r: &'static T) -> Pin<&'static T> {
    1663        // SAFETY: The 'static borrow guarantees the data will not be
    1664        // moved/invalidated until it gets dropped (which is never).
    1665        unsafe { Pin::new_unchecked(r) }
    1666    }
    1667}
    1668
    1669impl<T: ?Sized> Pin<&'static mut T> {
    1670    /// Gets a pinning mutable reference from a static mutable reference.
    1671    ///
    1672    /// This is safe because `T` is borrowed for the `'static` lifetime, which
    1673    /// never ends.
    1674    #[stable(feature = "pin_static_ref", since = "1.61.0")]
    1675    #[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
    1676    pub const fn static_mut(r: &'static mut T) -> Pin<&'static mut T> {
    1677        // SAFETY: The 'static borrow guarantees the data will not be
    1678        // moved/invalidated until it gets dropped (which is never).
    1679        unsafe { Pin::new_unchecked(r) }
    1680    }
    1681}
    1682
    1683#[stable(feature = "pin", since = "1.33.0")]
    1684#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1685impl<Ptr: [const] Deref> const Deref for Pin<Ptr> {
    1686    type Target = Ptr::Target;
    1687    fn deref(&self) -> &Ptr::Target {
    1688        Pin::get_ref(Pin::as_ref(self))
    1689    }
    1690}
    1691
    1692mod helper {
    1693    /// Helper that prevents downstream crates from implementing `DerefMut` for `Pin`.
    1694    ///
    1695    /// The `Pin` type implements the unsafe trait `PinCoerceUnsized`, which essentially requires
    1696    /// that the type does not have a malicious `Deref` or `DerefMut` impl. However, without this
    1697    /// helper module, downstream crates are able to write `impl DerefMut for Pin<LocalType>` as
    1698    /// long as it does not overlap with the impl provided by stdlib. This is because `Pin` is
    1699    /// `#[fundamental]`, so stdlib promises to never implement traits for `Pin` that it does not
    1700    /// implement today.
    1701    ///
    1702    /// However, this is problematic. Downstream crates could implement `DerefMut` for
    1703    /// `Pin<&LocalType>`, and they could do so maliciously. To prevent this, the implementation for
    1704    /// `Pin` delegates to this helper module. Since `helper::Pin` is not `#[fundamental]`, the
    1705    /// orphan rules assume that stdlib might implement `helper::DerefMut` for `helper::Pin<&_>` in
    1706    /// the future. Because of this, downstream crates can no longer provide an implementation of
    1707    /// `DerefMut` for `Pin<&_>`, as it might overlap with a trait impl that, according to the
    1708    /// orphan rules, the stdlib could introduce without a breaking change in a future release.
    1709    ///
    1710    /// See <https://github.com/rust-lang/rust/issues/85099> for the issue this fixes.
    1711    #[repr(transparent)]
    1712    #[unstable(feature = "pin_derefmut_internals", issue = "none")]
    1713    #[allow(missing_debug_implementations)]
    1714    pub struct PinHelper<Ptr> {
    1715        pointer: Ptr,
    1716    }
    1717
    1718    #[unstable(feature = "pin_derefmut_internals", issue = "none")]
    1719    #[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1720    #[rustc_diagnostic_item = "PinDerefMutHelper"]
    1721    pub const trait PinDerefMutHelper {
    1722        type Target: ?Sized;
    1723        fn deref_mut(&mut self) -> &mut Self::Target;
    1724    }
    1725
    1726    #[unstable(feature = "pin_derefmut_internals", issue = "none")]
    1727    #[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1728    impl<Ptr: [const] super::DerefMut> const PinDerefMutHelper for PinHelper<Ptr>
    1729    where
    1730        Ptr::Target: crate::marker::Unpin,
    1731    {
    1732        type Target = Ptr::Target;
    1733
    1734        #[inline(always)]
    1735        fn deref_mut(&mut self) -> &mut Ptr::Target {
    1736            &mut self.pointer
    1737        }
    1738    }
    1739}
    1740
    1741#[stable(feature = "pin", since = "1.33.0")]
    1742#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1743#[cfg(not(doc))]
    1744impl<Ptr> const DerefMut for Pin<Ptr>
    1745where
    1746    Ptr: [const] Deref,
    1747    helper::PinHelper<Ptr>: [const] helper::PinDerefMutHelper<Target = Self::Target>,
    1748{
    1749    #[inline]
    1750    fn deref_mut(&mut self) -> &mut Ptr::Target {
    1751        // SAFETY: Pin and PinHelper have the same layout, so this is equivalent to
    1752        // `&mut self.pointer` which is safe because `Target: Unpin`.
    1753        helper::PinDerefMutHelper::deref_mut(unsafe {
    1754            &mut *(self as *mut Pin<Ptr> as *mut helper::PinHelper<Ptr>)
    1755        })
    1756    }
    1757}
    1758
    1759/// The `Target` type is restricted to `Unpin` types as it's not safe to obtain a mutable reference
    1760/// to a pinned value.
    1761///
    1762/// For soundness reasons, implementations of `DerefMut` for `Pin<T>` are rejected even when `T` is
    1763/// a local type not covered by this impl block. (Since `Pin` is [fundamental], such implementations
    1764/// would normally be possible.)
    1765///
    1766/// [fundamental]: ../../reference/items/implementations.html#r-items.impl.trait.fundamental
    1767#[stable(feature = "pin", since = "1.33.0")]
    1768#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
    1769#[cfg(doc)]
    1770impl<Ptr> const DerefMut for Pin<Ptr>
    1771where
    1772    Ptr: [const] DerefMut,
    1773    <Ptr as Deref>::Target: Unpin,
    1774{
    1775    fn deref_mut(&mut self) -> &mut Ptr::Target {
    1776        Pin::get_mut(Pin::as_mut(self))
    1777    }
    1778}
    1779
    1780#[unstable(feature = "deref_pure_trait", issue = "87121")]
    1781unsafe impl<Ptr: DerefPure> DerefPure for Pin<Ptr> {}
    1782
    1783#[unstable(feature = "legacy_receiver_trait", issue = "none")]
    1784impl<Ptr: LegacyReceiver> LegacyReceiver for Pin<Ptr> {}
    1785
    1786#[stable(feature = "pin", since = "1.33.0")]
    1787impl<Ptr: fmt::Debug> fmt::Debug for Pin<Ptr> {
    1788    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
    1789        fmt::Debug::fmt(&self.pointer, f)
    1790    }
    1791}
    1792
    1793#[stable(feature = "pin", since = "1.33.0")]
    1794impl<Ptr: fmt::Display> fmt::Display for Pin<Ptr> {
    1795    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
    1796        fmt::Display::fmt(&self.pointer, f)
    1797    }
    1798}
    1799
    1800#[stable(feature = "pin", since = "1.33.0")]
    1801impl<Ptr: fmt::Pointer> fmt::Pointer for Pin<Ptr> {
    1802    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
    1803        fmt::Pointer::fmt(&self.pointer, f)
    1804    }
    1805}
    1806
    1807// Note: this means that any impl of `CoerceUnsized` that allows coercing from
    1808// a type that impls `Deref<Target=impl !Unpin>` to a type that impls
    1809// `Deref<Target=Unpin>` is unsound. Any such impl would probably be unsound
    1810// for other reasons, though, so we just need to take care not to allow such
    1811// impls to land in std.
    1812#[stable(feature = "pin", since = "1.33.0")]
    1813impl<Ptr, U> CoerceUnsized<Pin<U>> for Pin<Ptr>
    1814where
    1815    Ptr: CoerceUnsized<U> + PinCoerceUnsized,
    1816    U: PinCoerceUnsized,
    1817{
    1818}
    1819
    1820#[stable(feature = "pin", since = "1.33.0")]
    1821impl<Ptr, U> DispatchFromDyn<Pin<U>> for Pin<Ptr>
    1822where
    1823    Ptr: DispatchFromDyn<U> + PinCoerceUnsized,
    1824    U: PinCoerceUnsized,
    1825{
    1826}
    1827
    1828#[unstable(feature = "pin_coerce_unsized_trait", issue = "150112")]
    1829/// Trait that indicates that this is a pointer or a wrapper for one, where
    1830/// unsizing can be performed on the pointee when it is pinned.
    1831///
    1832/// # Safety
    1833///
    1834/// If this type implements `Deref`, then the concrete type returned by `deref`
    1835/// and `deref_mut` must not change without a modification. The following
    1836/// operations are not considered modifications:
    1837///
    1838/// * Moving the pointer.
    1839/// * Performing unsizing coercions on the pointer.
    1840/// * Performing dynamic dispatch with the pointer.
    1841/// * Calling `deref` or `deref_mut` on the pointer.
    1842///
    1843/// The concrete type of a trait object is the type that the vtable corresponds
    1844/// to. The concrete type of a slice is an array of the same element type and
    1845/// the length specified in the metadata. The concrete type of a sized type
    1846/// is the type itself.
    1847pub unsafe trait PinCoerceUnsized {}
    1848
    1849#[stable(feature = "pin", since = "1.33.0")]
    1850unsafe impl<'a, T: ?Sized> PinCoerceUnsized for &'a T {}
    1851
    1852#[stable(feature = "pin", since = "1.33.0")]
    1853unsafe impl<'a, T: ?Sized> PinCoerceUnsized for &'a mut T {}
    1854
    1855#[stable(feature = "pin", since = "1.33.0")]
    1856unsafe impl<T: PinCoerceUnsized> PinCoerceUnsized for Pin<T> {}
    1857
    1858#[stable(feature = "pin", since = "1.33.0")]
    1859unsafe impl<T: ?Sized> PinCoerceUnsized for *const T {}
    1860
    1861#[stable(feature = "pin", since = "1.33.0")]
    1862unsafe impl<T: ?Sized> PinCoerceUnsized for *mut T {}
    1863
    1864/// Constructs a <code>[Pin]<[&mut] T></code>, by pinning a `value: T` locally.
    1865///
    1866/// Unlike [`Box::pin`], this does not create a new heap allocation. As explained
    1867/// below, the element might still end up on the heap however.
    1868///
    1869/// The local pinning performed by this macro is usually dubbed "stack"-pinning.
    1870/// Outside of `async` contexts locals do indeed get stored on the stack. In
    1871/// `async` functions or blocks however, any locals crossing an `.await` point
    1872/// are part of the state captured by the `Future`, and will use the storage of
    1873/// those. That storage can either be on the heap or on the stack. Therefore,
    1874/// local pinning is a more accurate term.
    1875///
    1876/// If the type of the given value does not implement [`Unpin`], then this macro
    1877/// pins the value in memory in a way that prevents moves. On the other hand,
    1878/// if the type does implement [`Unpin`], <code>[Pin]<[&mut] T></code> behaves
    1879/// like <code>[&mut] T</code>, and operations such as
    1880/// [`mem::replace()`][crate::mem::replace] or [`mem::take()`](crate::mem::take)
    1881/// will allow moves of the value.
    1882/// See [the `Unpin` section of the `pin` module][self#unpin] for details.
    1883///
    1884/// ## Examples
    1885///
    1886/// ### Basic usage
    1887///
    1888/// ```rust
    1889/// # use core::marker::PhantomPinned as Foo;
    1890/// use core::pin::{pin, Pin};
    1891///
    1892/// fn stuff(foo: Pin<&mut Foo>) {
    1893///     // …
    1894///     # let _ = foo;
    1895/// }
    1896///
    1897/// let pinned_foo = pin!(Foo { /* … */ });
    1898/// stuff(pinned_foo);
    1899/// // or, directly:
    1900/// stuff(pin!(Foo { /* … */ }));
    1901/// ```
    1902///
    1903/// ### Manually polling a `Future` (without `Unpin` bounds)
    1904///
    1905/// ```rust
    1906/// use std::{
    1907///     future::Future,
    1908///     pin::pin,
    1909///     task::{Context, Poll},
    1910///     thread,
    1911/// };
    1912/// # use std::{sync::Arc, task::Wake, thread::Thread};
    1913///
    1914/// # /// A waker that wakes up the current thread when called.
    1915/// # struct ThreadWaker(Thread);
    1916/// #
    1917/// # impl Wake for ThreadWaker {
    1918/// #     fn wake(self: Arc<Self>) {
    1919/// #         self.0.unpark();
    1920/// #     }
    1921/// # }
    1922/// #
    1923/// /// Runs a future to completion.
    1924/// fn block_on<Fut: Future>(fut: Fut) -> Fut::Output {
    1925///     let waker_that_unparks_thread = // …
    1926///         # Arc::new(ThreadWaker(thread::current())).into();
    1927///     let mut cx = Context::from_waker(&waker_that_unparks_thread);
    1928///     // Pin the future so it can be polled.
    1929///     let mut pinned_fut = pin!(fut);
    1930///     loop {
    1931///         match pinned_fut.as_mut().poll(&mut cx) {
    1932///             Poll::Pending => thread::park(),
    1933///             Poll::Ready(res) => return res,
    1934///         }
    1935///     }
    1936/// }
    1937/// #
    1938/// # assert_eq!(42, block_on(async { 42 }));
    1939/// ```
    1940///
    1941/// ### With `Coroutine`s
    1942///
    1943/// ```rust
    1944/// #![feature(coroutines)]
    1945/// #![feature(coroutine_trait)]
    1946/// use core::{
    1947///     ops::{Coroutine, CoroutineState},
    1948///     pin::pin,
    1949/// };
    1950///
    1951/// fn coroutine_fn() -> impl Coroutine<Yield = usize, Return = ()> /* not Unpin */ {
    1952///  // Allow coroutine to be self-referential (not `Unpin`)
    1953///  // vvvvvv        so that locals can cross yield points.
    1954///     #[coroutine] static || {
    1955///         let foo = String::from("foo");
    1956///         let foo_ref = &foo; // ------+
    1957///         yield 0;                  // | <- crosses yield point!
    1958///         println!("{foo_ref}"); // <--+
    1959///         yield foo.len();
    1960///     }
    1961/// }
    1962///
    1963/// fn main() {
    1964///     let mut coroutine = pin!(coroutine_fn());
    1965///     match coroutine.as_mut().resume(()) {
    1966///         CoroutineState::Yielded(0) => {},
    1967///         _ => unreachable!(),
    1968///     }
    1969///     match coroutine.as_mut().resume(()) {
    1970///         CoroutineState::Yielded(3) => {},
    1971///         _ => unreachable!(),
    1972///     }
    1973///     match coroutine.resume(()) {
    1974///         CoroutineState::Yielded(_) => unreachable!(),
    1975///         CoroutineState::Complete(()) => {},
    1976///     }
    1977/// }
    1978/// ```
    1979///
    1980/// ## Remarks
    1981///
    1982/// Precisely because a value is pinned to local storage, the resulting <code>[Pin]<[&mut] T></code>
    1983/// reference ends up borrowing a local tied to that block: it can't escape it.
    1984///
    1985/// The following, for instance, fails to compile:
    1986///
    1987/// ```rust,compile_fail
    1988/// use core::pin::{pin, Pin};
    1989/// # use core::{marker::PhantomPinned as Foo, mem::drop as stuff};
    1990///
    1991/// let x: Pin<&mut Foo> = {
    1992///     let x: Pin<&mut Foo> = pin!(Foo { /* … */ });
    1993///     x
    1994/// }; // <- Foo is dropped
    1995/// stuff(x); // Error: use of dropped value
    1996/// ```
    1997///
    1998/// <details><summary>Error message</summary>
    1999///
    2000/// ```console
    2001/// error[E0716]: temporary value dropped while borrowed
    2002///   --> src/main.rs:9:28
    2003///    |
    2004/// 8  | let x: Pin<&mut Foo> = {
    2005///    |     - borrow later stored here
    2006/// 9  |     let x: Pin<&mut Foo> = pin!(Foo { /* … */ });
    2007///    |                            ^^^^^^^^^^^^^^^^^^^^^ creates a temporary value which is freed while still in use
    2008/// 10 |     x
    2009/// 11 | }; // <- Foo is dropped
    2010///    | - temporary value is freed at the end of this statement
    2011///    |
    2012///    = note: consider using a `let` binding to create a longer lived value
    2013/// ```
    2014///
    2015/// </details>
    2016///
    2017/// This makes [`pin!`] **unsuitable to pin values when intending to _return_ them**. Instead, the
    2018/// value is expected to be passed around _unpinned_ until the point where it is to be consumed,
    2019/// where it is then useful and even sensible to pin the value locally using [`pin!`].
    2020///
    2021/// If you really need to return a pinned value, consider using [`Box::pin`] instead.
    2022///
    2023/// On the other hand, local pinning using [`pin!`] is likely to be cheaper than
    2024/// pinning into a fresh heap allocation using [`Box::pin`]. Moreover, by virtue of not
    2025/// requiring an allocator, [`pin!`] is the main non-`unsafe` `#![no_std]`-compatible [`Pin`]
    2026/// constructor.
    2027///
    2028/// [`Box::pin`]: ../../std/boxed/struct.Box.html#method.pin
    2029#[stable(feature = "pin_macro", since = "1.68.0")]
    2030#[rustc_macro_transparency = "semiopaque"]
    2031#[allow_internal_unstable(super_let)]
    2032#[rustc_diagnostic_item = "pin_macro"]
    2033// `super` gets removed by rustfmt
    2034#[rustfmt::skip]
    2035pub macro pin($value:expr $(,)?) {
    2036    {
    2037        super let mut pinned = $value;
    2038        // SAFETY: The value is pinned: it is the local above which cannot be named outside this macro.
    2039        unsafe { $crate::pin::Pin::new_unchecked(&mut pinned) }
    2040    }
    2041}