File tree 1 file changed +4
-4
lines changed
1 file changed +4
-4
lines changed Original file line number Diff line number Diff line change 230
230
//! [`Pin<Ptr>`] to it *does not* actually change the way the compiler behaves towards the
231
231
//! inner value! It is possible to use incorrect [`unsafe`] code to create a [`Pin<Ptr>`] to a
232
232
//! 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
234
234
//! [`unsafe`], one may get access to a bare [`&mut T`] from a [`Pin<Ptr>`] and
235
235
//! use that to invalidly *move* pinned the value out. It is the job of the user of the
236
236
//! [`unsafe`] parts of the [`Pin`] API to ensure these invariants are not violated.
423
423
//! /// Create a new `Unmovable`.
424
424
//! ///
425
425
//! /// 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!
429
429
//! fn new() -> Pin<Box<Self>> {
430
430
//! let res = Unmovable {
431
431
//! data: [0; 64],
You can’t perform that action at this time.
0 commit comments