Rollup merge of #73425 - poliorcetics:zeroed-functions-pointers, r=dtolnay

Mention functions pointers in the documentation

Fixes #51615.

This mentions function pointers in the documentation for `core::mem::zeroed`, adding them to the list of types that are **always** wrong when zeroed, with `&T` and `&mut T`.

@rustbot modify labels: T-doc, C-enhancement, T-libs

src/libcore/mem/mod.rs

@@ -581,11 +581,12 @@ pub const fn needs_drop<T>() -> bool {
 /// 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
+/// There is no guarantee that an all-zero byte-pattern represents a valid value
-/// some type `T`. For example, the all-zero byte-pattern is not 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
+/// for reference types (`&T`, `&mut T`) and functions pointers. Using `zeroed`
-/// causes immediate [undefined behavior][ub] because [the Rust compiler assumes][inv]
+/// on such types causes immediate [undefined behavior][ub] because [the Rust
-/// that there always is a valid value in a variable it considers initialized.
+/// 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.
@@ -612,6 +613,7 @@ pub const fn needs_drop<T>() -> bool {
 /// use std::mem;
 ///
 /// let _x: &i32 = unsafe { mem::zeroed() }; // Undefined behavior!
+/// let _y: fn() = unsafe { mem::zeroed() }; // And again!
 /// ```
 #[inline(always)]
 #[stable(feature = "rust1", since = "1.0.0")]