New lint: lint against any `MaybeUninit::uninit()`

[tgross35]

What it does

Warn for any calls to MaybeUninit::uninit(). Alternatively, expand uninit_assumed_init to any uses of MaybeUninit::uninit() followed after some code by .assume_init().

Advantage

MaybeUninit::uninit() isn't unsound on its own, but it can be a bit of a footgun with libc types and other FFI. The issue is that a number of libc structs have padding that the system libc/kernel doesn't write, and occasionally there are new fields added. This means that fairly innocent looking code like this:

let mut s = MaybeUninit::<foo>::uninit();
libc::do_foo(s.as_mut_ptr());
return s.assume_init();

Can turn into UB if libc adds a field that hasn't yet made it to the local glibc version. Using zeroed instead is safe against this, and should be negligible to no cost.

Drawbacks

No response

Example

let mut s = MaybeUninit::<foo>::uninit();
libc::do_foo(s.as_mut_ptr());
return s.assume_init();

Could be written as:

let mut s = MaybeUninit::<foo>::zeroed();
libc::do_foo(s.as_mut_ptr());
return s.assume_init();

Comparison with existing lints

This is similar to clippy::uninit_assumed_init, though that specifically looks for MaybeUninit::uninit().assume_init().

Additional Context

Technically this doesn't need to warn if assume_init is never called, but that adds more difficulty to the lint.

[y21]

Does the disallowed_methods lint work for the general use case here of wanting to ban this function? E.g.

disallowed-methods = [
  { path = "std::mem::MaybeUninit::uninit", replacement = "std::mem::MaybeUninit::zeroed" }
]

(I'm assuming the proposed lint here would need to be opt-in either way, since this is still a correct way to use MaybeUninit in general and I don't think we should have a warn-by-default lint warn such a broad pattern that is usually correct -- unless we specifically check that it's a libc function call in between the uninit and assume_init call, but you did mention this applies to other kinds of FFI too).

I personally don't think clippy::uninit_assumed_init should be extended with this pattern. That one is very clearly always wrong, and it's a correctness lint which should not have any major false positives (for example that lint has extra checks to not lint if the target type is allowed to be uninit, like MaybeUninit::<[MaybeUninit<u8>; 8]>::uninit().assume_init()).