pin.rs source code [crates/core/src/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 libray author, it is your responsibility not to write something like
796	//! <code>impl\<T> [Unpin] for Struct\<T> {}</code> and then offer a method that provides
797	//! structural pinning to an inner field of `T`, which may not be [`Unpin`]! (Adding any
798	//! projection operation requires unsafe code, so the fact that [`Unpin`] is a safe trait does
799	//! not break the principle that you only have to worry about any of this if you use
800	//! [`unsafe`])
801	//!
802	//! 2. Pinned Destruction.* As discussed [above][drop-impl],* [`drop`] takes
803	//! [`&mut self`], but the struct (and hence its fields) might have been pinned
804	//! before. The destructor must be written as if its argument was
805	//! <code>self: [Pin]\<[`&mut Self`]></code>, instead.
806	//!
807	//! As a consequence, the struct must not* be [`#[repr(packed)]`][packed].*
808	//!
809	//! 3. Structural Notice of Destruction.* You must uphold the*
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
923	use crate::hash::{Hash, Hasher};
924	use crate::ops::{CoerceUnsized, Deref, DerefMut, DerefPure, DispatchFromDyn, LegacyReceiver};
925	#[allow(unused_imports)]
926	use crate::{
927	cell::{RefCell, UnsafeCell},
928	future::Future,
929	marker::PhantomPinned,
930	mem, ptr,
931	};
932	use crate::{cmp, fmt};
933
934	mod unsafe_pinned;
935
936	#[unstable(feature = "unsafe_pinned", issue = "125735")]
937	pub 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)]
1094	pub 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")]
1105	impl<Ptr: Deref, Q: Deref> PartialEq<Pin<Q>> for Pin<Ptr>
1106	where
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")]
1119	impl<Ptr: Deref<Target: Eq>> Eq for Pin<Ptr> {}
1120
1121	#[stable(feature = "pin_trait_impls", since = "1.41.0")]
1122	impl<Ptr: Deref, Q: Deref> PartialOrd<Pin<Q>> for Pin<Ptr>
1123	where
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")]
1148	impl<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")]
1155	impl<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
1161	impl<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
1217	impl<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	pub fn as_ref(&self) -> Pin<&Ptr::Target> {
1363	// SAFETY: see documentation on this function
1364	unsafe { Pin::new_unchecked(&*self.pointer) }
1365	}
1366	}
1367
1368	// These methods being in a `Ptr: DerefMut` impl block concerns semver stability.
1369	// Currently, calling e.g. `.set()` on a `Pin<&T>` sees that `Ptr: DerefMut`
1370	// doesn't hold, and goes to check for a `.set()` method on `T`. But, if the
1371	// `where Ptr: DerefMut` bound is moved to the method, rustc sees the impl block
1372	// as a valid candidate, and doesn't go on to check other candidates when it
1373	// sees that the bound on the method.
1374	impl<Ptr: DerefMut> Pin<Ptr> {
1375	/// Gets a mutable reference to the pinned value this `Pin<Ptr>` points to.
1376	///
1377	/// This is a generic method to go from `&mut Pin<Pointer<T>>` to `Pin<&mut T>`.
1378	/// It is safe because, as part of the contract of `Pin::new_unchecked`,
1379	/// the pointee cannot move after `Pin<Pointer<T>>` got created.
1380	/// "Malicious" implementations of `Pointer::DerefMut` are likewise
1381	/// ruled out by the contract of `Pin::new_unchecked`.
1382	///
1383	/// This method is useful when doing multiple calls to functions that consume the
1384	/// pinning pointer.
1385	///
1386	/// # Example
1387	///
1388	/// ```
1389	/// use std::pin::Pin;
1390	///
1391	/// # struct Type {}
1392	/// impl Type {
1393	/// fn method(self: Pin<&mut Self>) {
1394	/// // do something
1395	/// }
1396	///
1397	/// fn call_method_twice(mut self: Pin<&mut Self>) {
1398	/// // `method` consumes `self`, so reborrow the `Pin<&mut Self>` via `as_mut`.
1399	/// self.as_mut().method();
1400	/// self.as_mut().method();
1401	/// }
1402	/// }
1403	/// ```
1404	#[stable(feature = "pin", since = "1.33.0")]
1405	#[inline(always)]
1406	pub fn as_mut(&mut self) -> Pin<&mut Ptr::Target> {
1407	// SAFETY: see documentation on this function
1408	unsafe { Pin::new_unchecked(&mut *self.pointer) }
1409	}
1410
1411	/// Gets `Pin<&mut T>` to the underlying pinned value from this nested `Pin`-pointer.
1412	///
1413	/// This is a generic method to go from `Pin<&mut Pin<Pointer<T>>>` to `Pin<&mut T>`. It is
1414	/// safe because the existence of a `Pin<Pointer<T>>` ensures that the pointee, `T`, cannot
1415	/// move in the future, and this method does not enable the pointee to move. "Malicious"
1416	/// implementations of `Ptr::DerefMut` are likewise ruled out by the contract of
1417	/// `Pin::new_unchecked`.
1418	#[stable(feature = "pin_deref_mut", since = "1.84.0")]
1419	#[must_use = "`self` will be dropped if the result is not used"]
1420	#[inline(always)]
1421	pub fn as_deref_mut(self: Pin<&mut Self>) -> Pin<&mut Ptr::Target> {
1422	// SAFETY: What we're asserting here is that going from
1423	//
1424	// Pin<&mut Pin<Ptr>>
1425	//
1426	// to
1427	//
1428	// Pin<&mut Ptr::Target>
1429	//
1430	// is safe.
1431	//
1432	// We need to ensure that two things hold for that to be the case:
1433	//
1434	// 1) Once we give out a `Pin<&mut Ptr::Target>`, a `&mut Ptr::Target` will not be given out.
1435	// 2) By giving out a `Pin<&mut Ptr::Target>`, we do not risk violating
1436	// `Pin<&mut Pin<Ptr>>`
1437	//
1438	// The existence of `Pin<Ptr>` is sufficient to guarantee #1: since we already have a
1439	// `Pin<Ptr>`, it must already uphold the pinning guarantees, which must mean that
1440	// `Pin<&mut Ptr::Target>` does as well, since `Pin::as_mut` is safe. We do not have to rely
1441	// on the fact that `Ptr` is _also_ pinned.
1442	//
1443	// For #2, we need to ensure that code given a `Pin<&mut Ptr::Target>` cannot cause the
1444	// `Pin<Ptr>` to move? That is not possible, since `Pin<&mut Ptr::Target>` no longer retains
1445	// any access to the `Ptr` itself, much less the `Pin<Ptr>`.
1446	unsafe { self.get_unchecked_mut() }.as_mut()
1447	}
1448
1449	/// Assigns a new value to the memory location pointed to by the `Pin<Ptr>`.
1450	///
1451	/// This overwrites pinned data, but that is okay: the original pinned value's destructor gets
1452	/// run before being overwritten and the new value is also a valid value of the same type, so
1453	/// no pinning invariant is violated. See [the `pin` module documentation][subtle-details]
1454	/// for more information on how this upholds the pinning invariants.
1455	///
1456	/// # Example
1457	///
1458	/// ```
1459	/// use std::pin::Pin;
1460	///
1461	/// let mut val: u8 = `5`;
1462	/// let mut pinned: Pin<&mut u8> = Pin::new(&mut val);
1463	/// println!("{}", pinned); // 5
1464	/// pinned.set(`10`);
1465	/// println!("{}", pinned); // 10
1466	/// ```
1467	///
1468	/// [subtle-details]: self#subtle-details-and-the-drop-guarantee
1469	#[stable(feature = "pin", since = "1.33.0")]
1470	#[inline(always)]
1471	pub fn set(&mut self, value: Ptr::Target)
1472	where
1473	Ptr::Target: Sized,
1474	{
1475	*(self.pointer) = value;
1476	}
1477	}
1478
1479	impl<Ptr: Deref> Pin<Ptr> {
1480	/// Unwraps this `Pin<Ptr>`, returning the underlying `Ptr`.
1481	///
1482	/// # Safety
1483	///
1484	/// This function is unsafe. You must guarantee that you will continue to
1485	/// treat the pointer `Ptr` as pinned after you call this function, so that
1486	/// the invariants on the `Pin` type can be upheld. If the code using the
1487	/// resulting `Ptr` does not continue to maintain the pinning invariants that
1488	/// is a violation of the API contract and may lead to undefined behavior in
1489	/// later (safe) operations.
1490	///
1491	/// Note that you must be able to guarantee that the data pointed to by `Ptr`
1492	/// will be treated as pinned all the way until its `drop` handler is complete!
1493	///
1494	/// For more information, see the* [`pin` module docs][self]*
1495	///
1496	/// If the underlying data is [`Unpin`], [`Pin::into_inner`] should be used
1497	/// instead.
1498	#[inline(always)]
1499	#[rustc_allow_const_fn_unstable(const_precise_live_drops)]
1500	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1501	#[stable(feature = "pin_into_inner", since = "1.39.0")]
1502	pub const unsafe fn into_inner_unchecked(pin: Pin<Ptr>) -> Ptr {
1503	pin.pointer
1504	}
1505	}
1506
1507	impl<'a, T: ?Sized> Pin<&'a T> {
1508	/// Constructs a new pin by mapping the interior value.
1509	///
1510	/// For example, if you wanted to get a `Pin` of a field of something,
1511	/// you could use this to get access to that field in one line of code.
1512	/// However, there are several gotchas with these "pinning projections";
1513	/// see the [`pin` module] documentation for further details on that topic.
1514	///
1515	/// # Safety
1516	///
1517	/// This function is unsafe. You must guarantee that the data you return
1518	/// will not move so long as the argument value does not move (for example,
1519	/// because it is one of the fields of that value), and also that you do
1520	/// not move out of the argument you receive to the interior function.
1521	///
1522	/// [`pin` module]: self#projections-and-structural-pinning
1523	#[stable(feature = "pin", since = "1.33.0")]
1524	pub unsafe fn map_unchecked<U, F>(self, func: F) -> Pin<&'a U>
1525	where
1526	U: ?Sized,
1527	F: FnOnce(&T) -> &U,
1528	{
1529	let pointer = &*self.pointer;
1530	let new_pointer = func(pointer);
1531
1532	// SAFETY: the safety contract for `new_unchecked` must be
1533	// upheld by the caller.
1534	unsafe { Pin::new_unchecked(new_pointer) }
1535	}
1536
1537	/// Gets a shared reference out of a pin.
1538	///
1539	/// This is safe because it is not possible to move out of a shared reference.
1540	/// It may seem like there is an issue here with interior mutability: in fact,
1541	/// it is* possible to move a `T` out of a `&RefCell<T>`. However, this is*
1542	/// not a problem as long as there does not also exist a `Pin<&T>` pointing
1543	/// to the inner `T` inside the `RefCell`, and `RefCell<T>` does not let you get a
1544	/// `Pin<&T>` pointer to its contents. See the discussion on ["pinning projections"]
1545	/// for further details.
1546	///
1547	/// Note: `Pin` also implements `Deref` to the target, which can be used
1548	/// to access the inner value. However, `Deref` only provides a reference
1549	/// that lives for as long as the borrow of the `Pin`, not the lifetime of
1550	/// the reference contained in the `Pin`. This method allows turning the `Pin` into a reference
1551	/// with the same lifetime as the reference it wraps.
1552	///
1553	/// ["pinning projections"]: self#projections-and-structural-pinning
1554	#[inline(always)]
1555	#[must_use]
1556	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1557	#[stable(feature = "pin", since = "1.33.0")]
1558	pub const fn get_ref(self) -> &'a T {
1559	self.pointer
1560	}
1561	}
1562
1563	impl<'a, T: ?Sized> Pin<&'a mut T> {
1564	/// Converts this `Pin<&mut T>` into a `Pin<&T>` with the same lifetime.
1565	#[inline(always)]
1566	#[must_use = "`self` will be dropped if the result is not used"]
1567	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1568	#[stable(feature = "pin", since = "1.33.0")]
1569	pub const fn into_ref(self) -> Pin<&'a T> {
1570	Pin { pointer: self.pointer }
1571	}
1572
1573	/// Gets a mutable reference to the data inside of this `Pin`.
1574	///
1575	/// This requires that the data inside this `Pin` is `Unpin`.
1576	///
1577	/// Note: `Pin` also implements `DerefMut` to the data, which can be used
1578	/// to access the inner value. However, `DerefMut` only provides a reference
1579	/// that lives for as long as the borrow of the `Pin`, not the lifetime of
1580	/// the `Pin` itself. This method allows turning the `Pin` into a reference
1581	/// with the same lifetime as the original `Pin`.
1582	#[inline(always)]
1583	#[must_use = "`self` will be dropped if the result is not used"]
1584	#[stable(feature = "pin", since = "1.33.0")]
1585	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1586	pub const fn get_mut(self) -> &'a mut T
1587	where
1588	T: Unpin,
1589	{
1590	self.pointer
1591	}
1592
1593	/// Gets a mutable reference to the data inside of this `Pin`.
1594	///
1595	/// # Safety
1596	///
1597	/// This function is unsafe. You must guarantee that you will never move
1598	/// the data out of the mutable reference you receive when you call this
1599	/// function, so that the invariants on the `Pin` type can be upheld.
1600	///
1601	/// If the underlying data is `Unpin`, `Pin::get_mut` should be used
1602	/// instead.
1603	#[inline(always)]
1604	#[must_use = "`self` will be dropped if the result is not used"]
1605	#[stable(feature = "pin", since = "1.33.0")]
1606	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1607	pub const unsafe fn get_unchecked_mut(self) -> &'a mut T {
1608	self.pointer
1609	}
1610
1611	/// Constructs a new pin by mapping the interior value.
1612	///
1613	/// For example, if you wanted to get a `Pin` of a field of something,
1614	/// you could use this to get access to that field in one line of code.
1615	/// However, there are several gotchas with these "pinning projections";
1616	/// see the [`pin` module] documentation for further details on that topic.
1617	///
1618	/// # Safety
1619	///
1620	/// This function is unsafe. You must guarantee that the data you return
1621	/// will not move so long as the argument value does not move (for example,
1622	/// because it is one of the fields of that value), and also that you do
1623	/// not move out of the argument you receive to the interior function.
1624	///
1625	/// [`pin` module]: self#projections-and-structural-pinning
1626	#[must_use = "`self` will be dropped if the result is not used"]
1627	#[stable(feature = "pin", since = "1.33.0")]
1628	pub unsafe fn map_unchecked_mut<U, F>(self, func: F) -> Pin<&'a mut U>
1629	where
1630	U: ?Sized,
1631	F: FnOnce(&mut T) -> &mut U,
1632	{
1633	// SAFETY: the caller is responsible for not moving the
1634	// value out of this reference.
1635	let pointer = unsafe { Pin::get_unchecked_mut(self) };
1636	let new_pointer = func(pointer);
1637	// SAFETY: as the value of `this` is guaranteed to not have
1638	// been moved out, this call to `new_unchecked` is safe.
1639	unsafe { Pin::new_unchecked(new_pointer) }
1640	}
1641	}
1642
1643	impl<T: ?Sized> Pin<&'static T> {
1644	/// Gets a pinning reference from a `&'static` reference.
1645	///
1646	/// This is safe because `T` is borrowed immutably for the `'static` lifetime, which
1647	/// never ends.
1648	#[stable(feature = "pin_static_ref", since = "1.61.0")]
1649	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1650	pub const fn static_ref(r: &'static T) -> Pin<&'static T> {
1651	// SAFETY: The 'static borrow guarantees the data will not be
1652	// moved/invalidated until it gets dropped (which is never).
1653	unsafe { Pin::new_unchecked(pointer:r) }
1654	}
1655	}
1656
1657	impl<T: ?Sized> Pin<&'static mut T> {
1658	/// Gets a pinning mutable reference from a static mutable reference.
1659	///
1660	/// This is safe because `T` is borrowed for the `'static` lifetime, which
1661	/// never ends.
1662	#[stable(feature = "pin_static_ref", since = "1.61.0")]
1663	#[rustc_const_stable(feature = "const_pin", since = "1.84.0")]
1664	pub const fn static_mut(r: &'static mut T) -> Pin<&'static mut T> {
1665	// SAFETY: The 'static borrow guarantees the data will not be
1666	// moved/invalidated until it gets dropped (which is never).
1667	unsafe { Pin::new_unchecked(pointer:r) }
1668	}
1669	}
1670
1671	#[stable(feature = "pin", since = "1.33.0")]
1672	impl<Ptr: Deref> Deref for Pin<Ptr> {
1673	type Target = Ptr::Target;
1674	fn deref(&self) -> &Ptr::Target {
1675	Pin::get_ref(self:Pin::as_ref(self))
1676	}
1677	}
1678
1679	#[stable(feature = "pin", since = "1.33.0")]
1680	impl<Ptr: DerefMut<Target: Unpin>> DerefMut for Pin<Ptr> {
1681	fn deref_mut(&mut self) -> &mut Ptr::Target {
1682	Pin::get_mut(self:Pin::as_mut(self))
1683	}
1684	}
1685
1686	#[unstable(feature = "deref_pure_trait", issue = "87121")]
1687	unsafe impl<Ptr: DerefPure> DerefPure for Pin<Ptr> {}
1688
1689	#[unstable(feature = "legacy_receiver_trait", issue = "none")]
1690	impl<Ptr: LegacyReceiver> LegacyReceiver for Pin<Ptr> {}
1691
1692	#[stable(feature = "pin", since = "1.33.0")]
1693	impl<Ptr: fmt::Debug> fmt::Debug for Pin<Ptr> {
1694	fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1695	fmt::Debug::fmt(&self.pointer, f)
1696	}
1697	}
1698
1699	#[stable(feature = "pin", since = "1.33.0")]
1700	impl<Ptr: fmt::Display> fmt::Display for Pin<Ptr> {
1701	fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1702	fmt::Display::fmt(&self.pointer, f)
1703	}
1704	}
1705
1706	#[stable(feature = "pin", since = "1.33.0")]
1707	impl<Ptr: fmt::Pointer> fmt::Pointer for Pin<Ptr> {
1708	fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
1709	fmt::Pointer::fmt(&self.pointer, f)
1710	}
1711	}
1712
1713	// Note: this means that any impl of `CoerceUnsized` that allows coercing from
1714	// a type that impls `Deref<Target=impl !Unpin>` to a type that impls
1715	// `Deref<Target=Unpin>` is unsound. Any such impl would probably be unsound
1716	// for other reasons, though, so we just need to take care not to allow such
1717	// impls to land in std.
1718	#[stable(feature = "pin", since = "1.33.0")]
1719	impl<Ptr, U> CoerceUnsized<Pin<U>> for Pin<Ptr>
1720	where
1721	Ptr: CoerceUnsized<U> + PinCoerceUnsized,
1722	U: PinCoerceUnsized,
1723	{
1724	}
1725
1726	#[stable(feature = "pin", since = "1.33.0")]
1727	impl<Ptr, U> DispatchFromDyn<Pin<U>> for Pin<Ptr>
1728	where
1729	Ptr: DispatchFromDyn<U> + PinCoerceUnsized,
1730	U: PinCoerceUnsized,
1731	{
1732	}
1733
1734	#[unstable(feature = "pin_coerce_unsized_trait", issue = "123430")]
1735	/// Trait that indicates that this is a pointer or a wrapper for one, where
1736	/// unsizing can be performed on the pointee when it is pinned.
1737	///
1738	/// # Safety
1739	///
1740	/// If this type implements `Deref`, then the concrete type returned by `deref`
1741	/// and `deref_mut` must not change without a modification. The following
1742	/// operations are not considered modifications:
1743	///
1744	/// Moving the pointer.*
1745	/// Performing unsizing coercions on the pointer.*
1746	/// Performing dynamic dispatch with the pointer.*
1747	/// Calling `deref` or `deref_mut` on the pointer.*
1748	///
1749	/// The concrete type of a trait object is the type that the vtable corresponds
1750	/// to. The concrete type of a slice is an array of the same element type and
1751	/// the length specified in the metadata. The concrete type of a sized type
1752	/// is the type itself.
1753	pub unsafe trait PinCoerceUnsized {}
1754
1755	#[stable(feature = "pin", since = "1.33.0")]
1756	unsafe impl<'a, T: ?Sized> PinCoerceUnsized for &'a T {}
1757
1758	#[stable(feature = "pin", since = "1.33.0")]
1759	unsafe impl<'a, T: ?Sized> PinCoerceUnsized for &'a mut T {}
1760
1761	#[stable(feature = "pin", since = "1.33.0")]
1762	unsafe impl<T: PinCoerceUnsized> PinCoerceUnsized for Pin<T> {}
1763
1764	#[stable(feature = "pin", since = "1.33.0")]
1765	unsafe impl<T: ?Sized> PinCoerceUnsized for *const T {}
1766
1767	#[stable(feature = "pin", since = "1.33.0")]
1768	unsafe impl<T: ?Sized> PinCoerceUnsized for *mut T {}
1769
1770	/// Constructs a <code>[Pin]<[&mut] T></code>, by pinning a `value: T` locally.
1771	///
1772	/// Unlike [`Box::pin`], this does not create a new heap allocation. As explained
1773	/// below, the element might still end up on the heap however.
1774	///
1775	/// The local pinning performed by this macro is usually dubbed "stack"-pinning.
1776	/// Outside of `async` contexts locals do indeed get stored on the stack. In
1777	/// `async` functions or blocks however, any locals crossing an `.await` point
1778	/// are part of the state captured by the `Future`, and will use the storage of
1779	/// those. That storage can either be on the heap or on the stack. Therefore,
1780	/// local pinning is a more accurate term.
1781	///
1782	/// If the type of the given value does not implement [`Unpin`], then this macro
1783	/// pins the value in memory in a way that prevents moves. On the other hand,
1784	/// if the type does implement [`Unpin`], <code>[Pin]<[&mut] T></code> behaves
1785	/// like <code>[&mut] T</code>, and operations such as
1786	/// [`mem::replace()`][crate::mem::replace] or [`mem::take()`](crate::mem::take)
1787	/// will allow moves of the value.
1788	/// See [the `Unpin` section of the `pin` module][self#unpin] for details.
1789	///
1790	/// ## Examples
1791	///
1792	/// ### Basic usage
1793	///
1794	/// ```rust
1795	/// # use core::marker::PhantomPinned as Foo;
1796	/// use core::pin::{pin, Pin};
1797	///
1798	/// fn stuff(foo: Pin<&mut Foo>) {
1799	/// // …
1800	/// # let _ = foo;
1801	/// }
1802	///
1803	/// let pinned_foo = pin!(Foo { / … / });
1804	/// stuff(pinned_foo);
1805	/// // or, directly:
1806	/// stuff(pin!(Foo { / … / }));
1807	/// ```
1808	///
1809	/// ### Manually polling a `Future` (without `Unpin` bounds)
1810	///
1811	/// ```rust
1812	/// use std::{
1813	/// future::Future,
1814	/// pin::pin,
1815	/// task::{Context, Poll},
1816	/// thread,
1817	/// };
1818	/// # use std::{sync::Arc, task::Wake, thread::Thread};
1819	///
1820	/// # /// A waker that wakes up the current thread when called.
1821	/// # struct ThreadWaker(Thread);
1822	/// #
1823	/// # impl Wake for ThreadWaker {
1824	/// # fn wake(self: Arc<Self>) {
1825	/// # self.0.unpark();
1826	/// # }
1827	/// # }
1828	/// #
1829	/// /// Runs a future to completion.
1830	/// fn block_on<Fut: Future>(fut: Fut) -> Fut::Output {
1831	/// let waker_that_unparks_thread = // …
1832	/// # Arc::new(ThreadWaker(thread::current())).into();
1833	/// let mut cx = Context::from_waker(&waker_that_unparks_thread);
1834	/// // Pin the future so it can be polled.
1835	/// let mut pinned_fut = pin!(fut);
1836	/// loop {
1837	/// match pinned_fut.as_mut().poll(&mut cx) {
1838	/// Poll::Pending => thread::park(),
1839	/// Poll::Ready(res) => return res,
1840	/// }
1841	/// }
1842	/// }
1843	/// #
1844	/// # assert_eq!(`42`, block_on(async { `42` }));
1845	/// ```
1846	///
1847	/// ### With `Coroutine`s
1848	///
1849	/// ```rust
1850	/// #![feature(coroutines)]
1851	/// #![feature(coroutine_trait)]
1852	/// use core::{
1853	/// ops::{Coroutine, CoroutineState},
1854	/// pin::pin,
1855	/// };
1856	///
1857	/// fn coroutine_fn() -> impl Coroutine<Yield = usize, Return = ()> / not Unpin / {
1858	/// // Allow coroutine to be self-referential (not `Unpin`)
1859	/// // vvvvvv so that locals can cross yield points.
1860	/// #[coroutine] static \|\| {
1861	/// let foo = String::from("foo");
1862	/// let foo_ref = &foo; // ------+
1863	/// yield `0`; // \| <- crosses yield point!
1864	/// println!("{foo_ref}"); // <--+
1865	/// yield foo.len();
1866	/// }
1867	/// }
1868	///
1869	/// fn main() {
1870	/// let mut coroutine = pin!(coroutine_fn());
1871	/// match coroutine.as_mut().resume(()) {
1872	/// CoroutineState::Yielded(`0`) => {},
1873	/// _ => unreachable!(),
1874	/// }
1875	/// match coroutine.as_mut().resume(()) {
1876	/// CoroutineState::Yielded(`3`) => {},
1877	/// _ => unreachable!(),
1878	/// }
1879	/// match coroutine.resume(()) {
1880	/// CoroutineState::Yielded(_) => unreachable!(),
1881	/// CoroutineState::Complete(()) => {},
1882	/// }
1883	/// }
1884	/// ```
1885	///
1886	/// ## Remarks
1887	///
1888	/// Precisely because a value is pinned to local storage, the resulting <code>[Pin]<[&mut] T></code>
1889	/// reference ends up borrowing a local tied to that block: it can't escape it.
1890	///
1891	/// The following, for instance, fails to compile:
1892	///
1893	/// ```rust,compile_fail
1894	/// use core::pin::{pin, Pin};
1895	/// # use core::{marker::PhantomPinned as Foo, mem::drop as stuff};
1896	///
1897	/// let x: Pin<&mut Foo> = {
1898	/// let x: Pin<&mut Foo> = pin!(Foo { / … / });
1899	/// x
1900	/// }; // <- Foo is dropped
1901	/// stuff(x); // Error: use of dropped value
1902	/// ```
1903	///
1904	/// <details><summary>Error message</summary>
1905	///
1906	/// ```console
1907	/// error[E0716]: temporary value dropped while borrowed
1908	/// --> src/main.rs:9:28
1909	/// \|
1910	/// 8 \| let x: Pin<&mut Foo> = {
1911	/// \| - borrow later stored here
1912	/// 9 \| let x: Pin<&mut Foo> = pin!(Foo { / … / });
1913	/// \| ^^^^^^^^^^^^^^^^^^^^^ creates a temporary value which is freed while still in use
1914	/// 10 \| x
1915	/// 11 \| }; // <- Foo is dropped
1916	/// \| - temporary value is freed at the end of this statement
1917	/// \|
1918	/// = note: consider using a `let` binding to create a longer lived value
1919	/// ```
1920	///
1921	/// </details>
1922	///
1923	/// This makes [`pin!`] unsuitable to pin values when intending to _return_ them. Instead, the
1924	/// value is expected to be passed around _unpinned_ until the point where it is to be consumed,
1925	/// where it is then useful and even sensible to pin the value locally using [`pin!`].
1926	///
1927	/// If you really need to return a pinned value, consider using [`Box::pin`] instead.
1928	///
1929	/// On the other hand, local pinning using [`pin!`] is likely to be cheaper than
1930	/// pinning into a fresh heap allocation using [`Box::pin`]. Moreover, by virtue of not
1931	/// requiring an allocator, [`pin!`] is the main non-`unsafe` `#![no_std]`-compatible [`Pin`]
1932	/// constructor.
1933	///
1934	/// [`Box::pin`]: ../../std/boxed/struct.Box.html#method.pin
1935	#[stable(feature = "pin_macro", since = "1.68.0")]
1936	#[rustc_macro_transparency = "semitransparent"]
1937	#[allow_internal_unstable(super_let)]
1938	// `super` gets removed by rustfmt
1939	#[rustfmt::skip]
1940	pub macro pin($value:expr $(,)?) {
1941	{
1942	super let mut pinned = $value;
1943	// SAFETY: The value is pinned: it is the local above which cannot be named outside this macro.
1944	unsafe { $crate::pin::Pin::new_unchecked(&mut pinned) }
1945	}
1946	}
1947