Auto merge of #116074 - fzs111:clarify-pin-docs, r=Mark-Simulacrum

Clarify example in `Pin::new_unchecked` docs

This example in the docs of `Pin::new_unchecked` puzzled me for a relatively long time. Now I understand that it comes down to the difference between dropping the `Pin` vs dropping the pinned value.

I have extended the explanation to highlight this difference. In my opinion it is clearer now, and I hope it helps others understand `Pin` better.

Author: bors

library/core/src/pin.rs

@@ -572,7 +572,10 @@ impl<P: Deref> Pin<P> {
     ///     // though we have previously pinned it! We have violated the pinning API contract.
     /// }
     /// ```
-    /// A value, once pinned, must remain pinned forever (unless its type implements `Unpin`).
+    /// A value, once pinned, must remain pinned until it is dropped (unless its type implements
+    /// `Unpin`). Because `Pin<&mut T>` does not own the value, dropping the `Pin` will not drop
+    /// the value and will not end the pinning contract. So moving the value after dropping the
+    /// `Pin<&mut T>` is still a violation of the API contract.
     ///
     /// Similarly, calling `Pin::new_unchecked` on an `Rc<T>` is unsafe because there could be
     /// aliases to the same data that are not subject to the pinning restrictions: