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<T>`], 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 (<code>[&]T</code> and <code>[&mut] T</code>), etc., as well as many
 //! core and standard library types like [`Box<T>`], [`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.