fix: additional wording nits

Author: LuigiPiucco

library/core/src/ptr/mod.rs

@@ -28,7 +28,7 @@
 //!   undefined behavior to perform two concurrent accesses to the same location from different
 //!   threads unless both accesses only read from memory. Notice that this explicitly
 //!   includes [`read_volatile`] and [`write_volatile`]: Volatile accesses cannot
-//!   be used for inter-thread synchronization, regardless of whether it is acting on
+//!   be used for inter-thread synchronization, regardless of whether they are acting on
 //!   Rust memory or not.
 //! * The result of casting a reference to a pointer is valid for as long as the
 //!   underlying allocation is live and no reference (just raw pointers) is used to
@@ -2036,11 +2036,10 @@ pub const unsafe fn write_unaligned<T>(dst: *mut T, src: T) {
 /// - When a volatile operation is used for memory inside an [allocation], it behaves exactly like
 ///   [`read`], except for the additional guarantee that it won't be elided or reordered (see
 ///   above). This implies that the operation will actually access memory and not e.g. be lowered to
-///   reusing data from a previous read, such as from a register on which previous load of that
-///   memory was performed. Other than that, all the usual rules for memory accesses apply
-///   (including provenance).  In particular, just like in C, whether an operation is volatile has
-///   no bearing whatsoever on questions involving concurrent access from multiple threads. Volatile
-///   accesses behave exactly like non-atomic accesses in that regard.
+///   reusing data from a previous read. Other than that, all the usual rules for memory accesses
+///   apply (including provenance).  In particular, just like in C, whether an operation is volatile
+///   has no bearing whatsoever on questions involving concurrent accesses from multiple threads.
+///   Volatile accesses behave exactly like non-atomic accesses in that regard.
 ///
 /// - Volatile operations, however, may also be used to access memory that is _outside_ of any Rust
 ///   allocation. In this use-case, the pointer does *not* have to be [valid] for reads. This is
@@ -2050,10 +2049,11 @@ pub const unsafe fn write_unaligned<T>(dst: *mut T, src: T) {
 ///   Here, any address value is possible, including 0 and [`usize::MAX`], so long as the semantics
 ///   of such a read are well-defined by the target hardware. The provenance of the pointer is
 ///   irrelevant, and it can be created with [`without_provenance`]. The access must not trap. It
-///   can cause side-effects, but those must not affect Rust-allocated memory in in any way. This
+///   can cause side-effects, but those must not affect Rust-allocated memory in any way. This
 ///   access is still not considered [atomic], and as such it cannot be used for inter-thread
-///   synchronization. Note that volatile memory operations where T is a zero-sized type are noops
-///   and may be ignored.
+///   synchronization.
+///
+/// Note that volatile memory operations where T is a zero-sized type are noops and may be ignored.
 ///
 /// [allocation]: crate::ptr#allocated-object
 /// [atomic]: crate::sync::atomic#memory-model-for-atomic-accesses
@@ -2121,7 +2121,7 @@ pub unsafe fn read_volatile<T>(src: *const T) -> T {
 /// usage that need to be distinguished:
 ///
 /// - When a volatile operation is used for memory inside an [allocation], it behaves exactly like
-///   [`write()`], except for the additional guarantee that it won't be elided or reordered (see
+///   [`write`], except for the additional guarantee that it won't be elided or reordered (see
 ///   above). This implies that the operation will actually access memory and not e.g. be lowered to
 ///   a register access or stack pop. Other than that, all the usual rules for memory accesses apply
 ///   (including provenance). In particular, just like in C, whether an operation is volatile has no
@@ -2145,10 +2145,8 @@ pub unsafe fn read_volatile<T>(src: *const T) -> T {
 ///
 /// `write_volatile` does not drop the contents of `dst`. This is safe, but it could leak
 /// allocations or resources, so care should be taken not to overwrite an object that should be
-/// dropped when operating on Rust memory.
-///
-/// Additionally, it does not drop `src`. Semantically, `src` is moved into the location pointed to
-/// by `dst`.
+/// dropped when operating on Rust memory. Additionally, it does not drop `src`. Semantically, `src`
+/// is moved into the location pointed to by `dst`.
 ///
 /// [allocation]: crate::ptr#allocated-object
 /// [atomic]: crate::sync::atomic#memory-model-for-atomic-accesses