Rollup merge of #63215 - gnzlbg:patch-6, r=Centril

Clarify semantics of mem::zeroed

Clarifies the semantics of `mem::zeroed`.

r? @Centril

cc @RalfJung

src/libcore/mem/mod.rs

@@ -414,17 +414,20 @@ pub const fn needs_drop<T>() -> bool {
     intrinsics::needs_drop::<T>()
 }
 
-/// Creates a value whose bytes are all zero.
+/// Returns the value of type `T` represented by the all-zero byte-pattern.
 ///
-/// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed].
-/// It is useful for FFI sometimes, but should generally be avoided.
+/// This means that, for example, the padding byte in `(u8, u16)` is not
+/// necessarily zeroed.
 ///
 /// There is no guarantee that an all-zero byte-pattern represents a valid value of
 /// some type `T`. For example, the all-zero byte-pattern is not a valid value
 /// for reference types (`&T` and `&mut T`). Using `zeroed` on such types
 /// causes immediate [undefined behavior][ub] because [the Rust compiler assumes][inv]
 /// that there always is a valid value in a variable it considers initialized.
 ///
+/// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed].
+/// It is useful for FFI sometimes, but should generally be avoided.
+///
 /// [zeroed]: union.MaybeUninit.html#method.zeroed
 /// [ub]: ../../reference/behavior-considered-undefined.html
 /// [inv]: union.MaybeUninit.html#initialization-invariant