From 9e7c00b0e90c7c0c01cb06ac86e5e0b27607d420 Mon Sep 17 00:00:00 2001 From: Herobs Date: Sat, 23 Mar 2024 16:51:40 +0800 Subject: [PATCH] Fix some typos in the pin.rs --- library/core/src/pin.rs | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/library/core/src/pin.rs b/library/core/src/pin.rs index a0227d9130b..d14cac9afb5 100644 --- a/library/core/src/pin.rs +++ b/library/core/src/pin.rs @@ -144,7 +144,7 @@ //! * e.g. [`drop`]ping the [`Future`] [^pin-drop-future] //! //! There are two possible ways to ensure the invariants required for 2. and 3. above (which -//! apply to any address-sensitive type, not just self-referrential types) do not get broken. +//! apply to any address-sensitive type, not just self-referential types) do not get broken. //! //! 1. Have the value detect when it is moved and update all the pointers that point to itself. //! 2. Guarantee that the address of the value does not change (and that memory is not re-used @@ -170,7 +170,7 @@ //! become viral throughout all code that interacts with the object. //! //! The second option is a viable solution to the problem for some use cases, in particular -//! for self-referrential types. Under this model, any type that has an address sensitive state +//! for self-referential types. Under this model, any type that has an address sensitive state //! would ultimately store its data in something like a [`Box`], carefully manage internal //! access to that data to ensure no *moves* or other invalidation occurs, and finally //! provide a safe interface on top. @@ -186,8 +186,8 @@ //! //! Although there were other reason as well, this issue of expensive composition is the key thing //! that drove Rust towards adopting a different model. It is particularly a problem -//! when one considers, for exapmle, the implications of composing together the [`Future`]s which -//! will eventaully make up an asynchronous task (including address-sensitive `async fn` state +//! when one considers, for example, the implications of composing together the [`Future`]s which +//! will eventually make up an asynchronous task (including address-sensitive `async fn` state //! machines). It is plausible that there could be many layers of [`Future`]s composed together, //! including multiple layers of `async fn`s handling different parts of a task. It was deemed //! unacceptable to force indirection and allocation for each layer of composition in this case. @@ -359,7 +359,7 @@ //! Builtin types that are [`Unpin`] include all of the primitive types, like [`bool`], [`i32`], //! and [`f32`], references ([&]T and [&mut] T), etc., as well as many //! core and standard library types like [`Box`], [`String`], and more. -//! These types are marked [`Unpin`] because they do not have an ddress-sensitive state like the +//! These types are marked [`Unpin`] because they do not have an address-sensitive state like the //! ones we discussed above. If they did have such a state, those parts of their interface would be //! unsound without being expressed through pinning, and they would then need to not //! implement [`Unpin`]. @@ -953,7 +953,7 @@ /// discussed below. /// /// We call such a [`Pin`]-wrapped pointer a **pinning pointer** (or pinning ref, or pinning -/// [`Box`], etc.) because its existince is the thing that is pinning the underlying pointee in +/// [`Box`], etc.) because its existence is the thing that is pinning the underlying pointee in /// place: it is the metaphorical "pin" securing the data in place on the pinboard (in memory). /// /// It is important to stress that the thing in the [`Pin`] is not the value which we want to pin @@ -962,7 +962,7 @@ /// /// The most common set of types which require pinning related guarantees for soundness are the /// compiler-generated state machines that implement [`Future`] for the return value of -/// `async fn`s. These compiler-generated [`Future`]s may contain self-referrential pointers, one +/// `async fn`s. These compiler-generated [`Future`]s may contain self-referential pointers, one /// of the most common use cases for [`Pin`]. More details on this point are provided in the /// [`pin` module] docs, but suffice it to say they require the guarantees provided by pinning to /// be implemented soundly.