OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Remove [mut] syntax in pin docs

Browse Source
This commit is contained in:
Chris Gregory 2019-04-11 21:21:19 -05:00
parent 3de0106789
commit 94a5c3b2b2
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/libcore/pin.rs
View File

@ -158,12 +158,12 @@
//! is called *even if your type was previously pinned*! It is as if the //! is called *even if your type was previously pinned*! It is as if the
//! compiler automatically called `get_unchecked_mut`. //! compiler automatically called `get_unchecked_mut`.
//! //!
//! This can never cause a problem in safe code because implementing a type that relies on pinning //! This can never cause a problem in safe code because implementing a type that
//! requires unsafe code, but be aware that deciding to make use of pinning //! relies on pinning requires unsafe code, but be aware that deciding to make
//! in your type (for example by implementing some operation on `Pin<&[mut] Self>`) //! use of pinning in your type (for example by implementing some operation on
//! has consequences for your `Drop` implementation as well: if an element //! `Pin<&Self>` or `Pin<&mut Self>`) has consequences for your `Drop`
//! of your type could have been pinned, you must treat Drop as implicitly taking //! implementation as well: if an element of your type could have been pinned,
//! `Pin<&mut Self>`. //! you must treat Drop as implicitly taking `Pin<&mut Self>`.
//! //!
//! In particular, if your type is `#[repr(packed)]`, the compiler will automatically //! In particular, if your type is `#[repr(packed)]`, the compiler will automatically
//! move fields around to be able to drop them. As a consequence, you cannot use //! move fields around to be able to drop them. As a consequence, you cannot use
@ -173,13 +173,13 @@
//! //!
//! One interesting question arises when considering the interaction of pinning and //! One interesting question arises when considering the interaction of pinning and
//! the fields of a struct. When can a struct have a "pinning projection", i.e., //! the fields of a struct. When can a struct have a "pinning projection", i.e.,
//! an operation with type `fn(Pin<&[mut] Struct>) -> Pin<&[mut] Field>`? //! an operation with type `fn(Pin<&Struct>) -> Pin<&Field>`?
//! In a similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, or `RefCell<T>`) //! In a similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, or `RefCell<T>`)
//! have an operation with type `fn(Pin<&[mut] Wrapper<T>>) -> Pin<&[mut] T>`? //! have an operation with type `fn(Pin<&Wrapper<T>>) -> Pin<&T>`?
//! //!
//! Having a pinning projection for some field means that pinning is "structural": //! Having a pinning projection for some field means that pinning is "structural":
//! when the wrapper is pinned, the field must be considered pinned, too. //! when the wrapper is pinned, the field must be considered pinned, too.
//! After all, the pinning projection lets us get a `Pin<&[mut] Field>`. //! After all, the pinning projection lets us get a `Pin<&Field>`.
//! //!
//! However, structural pinning comes with a few extra requirements, so not all //! However, structural pinning comes with a few extra requirements, so not all
//! wrappers can be structural and hence not all wrappers can offer pinning projections: //! wrappers can be structural and hence not all wrappers can offer pinning projections: