Implement MaybeUninit::fill{,_cloned,_mut,_with,_from}

[jmillikin]

ACP: rust-lang/libs-team#156

Tracking issue: #117428

[rustbot]

r? @joshtriplett

(rustbot has picked a reviewer for you, use r? to override)

[jmillikin]

@rustbot label +T-libs-api -T-libs

[jmillikin]

The original ACP proposed adding fill<T: Clone>(&mut self, value: T) -> &mut [T] -- I made the following adjustments to this API:

• Changed the value parameter to &T to have better control over Drop handling.
  • To match existing test behavior I try to be careful about how many drop() calls happen. There was no good way to avoid dropping value if called with an empty slice, but in all other slice sizes the value does not need to be dropped, which made the behavior ambiguous if the parameter is moved vs borrowed.
• Changed to return a non-mutable slice to avoid the accidental leaking discussed in MaybeUninit::write_slice_cloned() makes it very easy to accidentally leak #80376
• To accommodate the common case of filling with zero or a known bit pattern, I renamed the Clone fill method to fill_cloned() and added fill() / fill_mut() for T: Copy -- the mut slice return isn't dangerous since there's no dropping.

The ACP's proposed fill_with<F: FnMut() -> T>(f: F) and fill_from<I: Iterator<Item = T>>(iter: I) were implemented as originally described.

I verified that MaybeUninit<u8>::fill() compiles to memset().

[jmillikin]

r? @m-ou-se

[Amanieu]

* Changed to return a non-mutable slice to avoid the accidental leaking discussed in [MaybeUninit::write_slice_cloned() makes it very easy to accidentally leak #80376](https://github.com/rust-lang/rust/issues/80376)

I disagree. I think this should always return &mut. I think introducing more API surface will only increase user confusion, and by working with MaybeUninit you already have to be aware of potentially leaking data. All the fill methods should return mutable slices.

* To accommodate the common case of filling with zero or a known bit pattern, I renamed the `Clone` fill method to `fill_cloned()` and added `fill()` / `fill_mut()` for `T: Copy` -- the mut slice return isn't dangerous since there's no dropping.

I'm less concerned about this: there is already fill_with for people who want precise control over how many clone calls are made. The discussion about T vs &T has already happened in #70758, and I would prefer just keeping the T version for consistency with slice::fill.

[bors]

☔ The latest upstream changes (presumably #116385) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

@rustbot author

[Amanieu]

ping @jmillikin, could you address the review feedback?

[jmillikin]

Closed in favor of #121280