std: refactor explanation of NonNull

Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>

Author: xizheyin

library/core/src/ptr/non_null.rs

@@ -11,36 +11,23 @@ use crate::{fmt, hash, intrinsics, mem, ptr};
 
 /// `*mut T` but non-zero and [covariant].
 ///
-/// This is often the correct thing to use when building data structures using
-/// raw pointers, but is ultimately more dangerous to use because of its additional
-/// properties. If you're not sure if you should use `NonNull<T>`, just use `*mut T`!
+/// `NonNull<T>` is a non-null raw pointer, commonly used for building data structures with raw pointers.
+/// It is **covariant** over `T`, which is the correct choice for most safe abstractions (such as `Box`, `Rc`, `Arc`, `Vec`, etc).
 ///
-/// Unlike `*mut T`, the pointer must always be non-null, even if the pointer
-/// is never dereferenced. This is so that enums may use this forbidden value
-/// as a discriminant -- `Option<NonNull<T>>` has the same size as `*mut T`.
-/// However the pointer may still dangle if it isn't dereferenced.
+/// If you need **invariance** (for example, when implementing types like `Cell<T>`), you can add a marker field to your type:
 ///
-/// Unlike `*mut T`, `NonNull<T>` was chosen to be covariant over `T`. This makes it
-/// possible to use `NonNull<T>` when building covariant types, but introduces the
-/// risk of unsoundness if used in a type that shouldn't actually be covariant.
-/// (The opposite choice was made for `*mut T` even though technically the unsoundness
-/// could only be caused by calling unsafe functions.)
-///
-/// Covariance is correct for most safe abstractions, such as `Box`, `Rc`, `Arc`, `Vec`,
-/// and `LinkedList`. This is the case because they provide a public API that follows the
-/// normal shared XOR mutable rules of Rust.
+/// ```rust
+/// use std::marker::PhantomData;
+/// use std::cell::Cell;
+/// use std::ptr::NonNull;
 ///
-/// If your type cannot safely be covariant, you must ensure it contains some
-/// additional field to provide invariance. Often this field will be a [`PhantomData`]
-/// type like `PhantomData<Cell<T>>` or `PhantomData<&'a mut T>`.
+/// struct MyCell<T> {
+///     ptr: NonNull<T>,
+///     _invariant: PhantomData<Cell<T>>,
+/// }
+/// ```
 ///
-/// Notice that `NonNull<T>` has a `From` instance for `&T`. However, this does
-/// not change the fact that mutating through a (pointer derived from a) shared
-/// reference is undefined behavior unless the mutation happens inside an
-/// [`UnsafeCell<T>`]. The same goes for creating a mutable reference from a shared
-/// reference. When using this `From` instance without an `UnsafeCell<T>`,
-/// it is your responsibility to ensure that `as_mut` is never called, and `as_ptr`
-/// is never used for mutation.
+/// In most cases, you should use `NonNull<T>` when you want a non-null pointer. If you are unsure, using a raw pointer (`*mut T`) is also fine.
 ///
 /// # Representation
 ///