Skip to content

Commit 2dd8436

Browse files
authored
Rollup merge of rust-lang#59900 - czipperz:remove-bracket-mut-syntax-in-pin-docs, r=RalfJung
Remove [mut] syntax in pin docs Resolves rust-lang#59832
2 parents f9c5068 + b754b8f commit 2dd8436

File tree

1 file changed

+16
-12
lines changed

1 file changed

+16
-12
lines changed

src/libcore/pin.rs

+16-12
Original file line numberDiff line numberDiff line change
@@ -158,28 +158,32 @@
158158
//! is called *even if your type was previously pinned*! It is as if the
159159
//! compiler automatically called `get_unchecked_mut`.
160160
//!
161-
//! This can never cause a problem in safe code because implementing a type that relies on pinning
162-
//! requires unsafe code, but be aware that deciding to make use of pinning
163-
//! in your type (for example by implementing some operation on `Pin<&[mut] Self>`)
164-
//! has consequences for your `Drop` implementation as well: if an element
165-
//! of your type could have been pinned, you must treat Drop as implicitly taking
166-
//! `Pin<&mut Self>`.
161+
//! This can never cause a problem in safe code because implementing a type that
162+
//! relies on pinning requires unsafe code, but be aware that deciding to make
163+
//! use of pinning in your type (for example by implementing some operation on
164+
//! `Pin<&Self>` or `Pin<&mut Self>`) has consequences for your `Drop`
165+
//! implementation as well: if an element of your type could have been pinned,
166+
//! you must treat Drop as implicitly taking `Pin<&mut Self>`.
167167
//!
168168
//! In particular, if your type is `#[repr(packed)]`, the compiler will automatically
169169
//! move fields around to be able to drop them. As a consequence, you cannot use
170170
//! pinning with a `#[repr(packed)]` type.
171171
//!
172172
//! # Projections and Structural Pinning
173173
//!
174-
//! One interesting question arises when considering the interaction of pinning and
175-
//! the fields of a struct. When can a struct have a "pinning projection", i.e.,
176-
//! an operation with type `fn(Pin<&[mut] Struct>) -> Pin<&[mut] Field>`?
177-
//! In a similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, or `RefCell<T>`)
178-
//! have an operation with type `fn(Pin<&[mut] Wrapper<T>>) -> Pin<&[mut] T>`?
174+
//! One interesting question arises when considering the interaction of pinning
175+
//! and the fields of a struct. When can a struct have a "pinning projection",
176+
//! i.e., an operation with type `fn(Pin<&Struct>) -> Pin<&Field>`? In a
177+
//! similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`,
178+
//! or `RefCell<T>`) have an operation with type `fn(Pin<&Wrapper<T>>) ->
179+
//! Pin<&T>`?
180+
//!
181+
//! Note: For the entirety of this discussion, the same applies for mutable references as it
182+
//! does for shared references.
179183
//!
180184
//! Having a pinning projection for some field means that pinning is "structural":
181185
//! when the wrapper is pinned, the field must be considered pinned, too.
182-
//! After all, the pinning projection lets us get a `Pin<&[mut] Field>`.
186+
//! After all, the pinning projection lets us get a `Pin<&Field>`.
183187
//!
184188
//! However, structural pinning comes with a few extra requirements, so not all
185189
//! wrappers can be structural and hence not all wrappers can offer pinning projections:

0 commit comments

Comments
 (0)