Tracking issue for future-incompatibility lint `mem_uninitialized`

[5225225]

Important

This lint has not been implemented yet! See #100342.

This is the summary issue for the mem_uninitialized
future-compatibility warning and other related errors. The goal of
this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions
or register a complaint if you feel the change should not be made. For
more information on the policy around future-compatibility warnings,
see our breaking change policy guidelines.

What is the warning for?

This warning will trigger whenever std::mem::uninitialized is used, unless the type returned consists of only raw pointers, integers, and floats.

As an example, uninitialized::<[char; 64]> will trigger the warning, but uninitialized::<[u8; 64]> will not. Additionally, in generic methods, uninitialized::<T> will trigger the warning, even though T might be a [u8; 64] when it is used.

To fix the warning, use std::mem::MaybeUninit, and only assume_init once the value is fully initialized. Note that even though we do not warn for uninitialized integers here, it is still undefined behavior to create uninitialized integers.

The change to warn here was made in order to get notified when their dependencies inappropriately use mem::uninitialized, which can lead to runtime panics depending on the type (as tracked in #66151). Using a lint here is less surprising than a runtime panic, and allows people to get notification of code that may break at runtime, earlier.

When will this warning become a hard error?

Unlike other future-compat warnings, this is never intended to be a hard error, it is purely to warn users about dangerous uses of mem::uninitialized in their dependency tree.

[5225225]

Note: I'm making this now to register the number so I can add it to the implementation PR (#100342), the exact places where this will lint on is not finalized, but what's described here is what's currently implemented.

Also, I diverged from the template at the end, I suppose the wording here is okay? This is the only FCW that will never actually become a hard error (So I suppose it will exist forever?).

@rustbot label +C-future-compatibility +C-tracking-issue