Partially stabilize maybe_uninit_extra

[ojeda]

This covers:

impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}

It does not cover the const-ness of write under const_maybe_uninit_write nor the const-ness of assume_init_read (this commit adds const_maybe_uninit_assume_init_read for that).

FCP: #63567 (comment).

Signed-off-by: Miguel Ojeda ojeda@kernel.org

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

It looks like the FCP included the const-ness of MaybeUninit::write -- was that excluded for a reason?

#63567 (comment)

[jhpratt]

Not the person who created the PR, but &mut parameters aren't permitted in const fn on stable. I would imagine some lint would fire if we were to try to stabilize it as-is.

MaybeUninit::assume_init_read() shouldn't have any blockers to be const fn, but at the same time it wasn't part of the FCP.

[Mark-Simulacrum]

Ah, ok. That makes sense.

@bors r+ rollup

[bors]

📌 Commit 8680a44 has been approved by Mark-Simulacrum

[ojeda]

Not the person who created the PR, but &mut parameters aren't permitted in const fn on stable. I would imagine some lint would fire if we were to try to stabilize it as-is.

Exactly, plus assume_init_mut is not const-stable. Given we only use the non-const bits in the kernel (so far, at least), I thought it was worth getting this part in at least.

MaybeUninit::assume_init_read() shouldn't have any blockers to be const fn, but at the same time it wasn't part of the FCP.

I did not try since it was not part of the FCP, but from a quick test, we would need const_ptr_read.