[BUG] Safety comments for MaybeUninit::assume_init calls are wrong, calls are UB

[saethlin]

This code executes UB:

rust-lexical/lexical-write-float/src/radix.rs

Lines 70 to 72 in 09c686b

	let buffer: mem::MaybeUninit<[u8; SIZE]> = mem::MaybeUninit::uninit();
	// SAFETY: safe, since we never read bytes that weren't written.
	let mut buffer = unsafe { buffer.assume_init() };

The docs for MaybeUninit::uninit do not have an exception for this use case. This code is UB, because the MaybeUninit is not initialized.

The safety comment is also technically wrong; the value is read by the assignment and return from MaybeUninit::assume_init.

This problem is reliably reported by running cargo +nightly miri test --all-features.

---

The existing MaybeUninit APIs are not exactly elegant, but I think they can be slotted in pretty neatly with the existing abstractions you have here. I can take a shot at fixing this in the coming days/weeks.

[Alexhuszagh]

I'll prioritize this later today. I did not realize this was the case. I'll likely add in miri checks into our CI pipeline. I'll see if migrating it to zeroed affects anything. I was (incorrectly) under the assumption ptr.write() was defined behavior, such as shown in the examples but didn't realize the assignment affected that.

use std::mem::MaybeUninit;

// Create an explicitly uninitialized reference. The compiler knows that data inside
// a `MaybeUninit<T>` may be invalid, and hence this is not UB:
let mut x = MaybeUninit::<&i32>::uninit();
// Set it to a valid value.
x.write(&0);
// Extract the initialized data -- this is only allowed *after* properly
// initializing `x`!
let x = unsafe { x.assume_init() };