Skip to content

Commit b6afd3e

Browse files
committed
fix typos
1 parent b736faf commit b6afd3e

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

library/core/src/pin.rs

+4-4
Original file line numberDiff line numberDiff line change
@@ -230,7 +230,7 @@
230230
//! [`Pin<Ptr>`] to it *does not* actually change the way the compiler behaves towards the
231231
//! inner value! It is possible to use incorrect [`unsafe`] code to create a [`Pin<Ptr>`] to a
232232
//! value which does not actually satisfy the invariants that a pinned value must satisfy, and in
233-
//! this way lead undefined behavior even in (from that point) fully safe code. Similarly, using
233+
//! this way lead to undefined behavior even in (from that point) fully safe code. Similarly, using
234234
//! [`unsafe`], one may get access to a bare [`&mut T`] from a [`Pin<Ptr>`] and
235235
//! use that to invalidly *move* pinned the value out. It is the job of the user of the
236236
//! [`unsafe`] parts of the [`Pin`] API to ensure these invariants are not violated.
@@ -423,9 +423,9 @@
423423
//! /// Create a new `Unmovable`.
424424
//! ///
425425
//! /// To ensure the data doesn't move we place it on the heap behind a pinning Box.
426-
//! /// Note that the data is pinned, but the which is pinning it can itself still be moved.
427-
//! /// This is important because it means we can return the pointer from the function, which
428-
//! /// is itself a kind of move!
426+
//! /// Note that the data is pinned, but the `Pin<Box<Self>>` which is pinning it can
427+
//! /// itself still be moved. This is important because it means we can return the pinning
428+
//! /// pointer from the function, which is itself a kind of move!
429429
//! fn new() -> Pin<Box<Self>> {
430430
//! let res = Unmovable {
431431
//! data: [0; 64],

0 commit comments

Comments
 (0)