Partially stabilize `feature(new_uninit)`

[workingjubilee]

Finished comment period: https://github.com/rust-lang/rust/issues/63291#issuecomment-2183022955

The following API has been stabilized from https://github.com/rust-lang/rust/issues/63291

impl<T> Box<T> { pub fn new_uninit() -> Box<MaybeUninit<T>> {…} }
impl<T> Rc<T> { pub fn new_uninit() -> Rc<MaybeUninit<T>> {…} }
impl<T> Arc<T> { pub fn new_uninit() -> Arc<MaybeUninit<T>> {…} }

impl<T> Box<[T]> { pub fn new_uninit_slice(len: usize) -> Box<[MaybeUninit<T>]> {…} }
impl<T> Rc<[T]> { pub fn new_uninit_slice(len: usize) -> Rc<[MaybeUninit<T>]> {…} }
impl<T> Arc<[T]> { pub fn new_uninit_slice(len: usize) -> Arc<[MaybeUninit<T>]> {…} }

impl<T> Box<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Box<T> {…} }
impl<T> Box<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Box<[T]> {…} }
impl<T> Rc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Rc<T> {…} }
impl<T> Rc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Rc<[T]> {…} }
impl<T> Arc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Arc<T> {…} }
impl<T> Arc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Arc<[T]> {…} }

The remaining API is split between new issues

• new_zeroed_alloc: https://github.com/rust-lang/rust/issues/129396
• box_uninit_write: https://github.com/rust-lang/rust/issues/129397

All relevant code is thus either stabilized or split out of that issue, so this closes #63291 as, with the FCP concluded, that issue has served its purpose.

try-job: x86_64-rust-for-linux

[rustbot]

r? @joboet

rustbot has assigned @joboet. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[workingjubilee]

This goes into the relnotes because:

• ...it's new API. We're still adding that to relnotes, right?

[joboet]

@rust-lang/libs-api I have a question before I merge this: Is there a reason these functions aren't named uninit/uninit_slice? I find that to be just as clear and a bit more concise, and MaybeUninit::uninit isn't called new_uninit either.

[bors]

:umbrella: The latest upstream changes (presumably #129563) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

@bors try

[bors]

:hourglass: Trying commit ae88be497c7bdbf4384a45cbf1c504bef0d7704f with merge b8a70e08cf21cfc4847acd0f5f806ffeb5ea1620...

[bors]

:sunny: Try build successful - checks-actions Build commit: b8a70e08cf21cfc4847acd0f5f806ffeb5ea1620 (b8a70e08cf21cfc4847acd0f5f806ffeb5ea1620)

[dtolnay]

Is there a reason these functions aren't named uninit/uninit_slice?

We discussed this suggestion in today's @rust-lang/libs-api meeting. Considering only new/uninit/uninit_slice, the suggested set of names makes sense. But there is a suite of other constructors on Box, and omitting new_ is not a naming scheme that would consistently work.

If we were to go with renaming new_uninit->uninit, we would also want new_uninit_in->uninit_in and try_new_uninit->try_uninit. But then we would further want new_in->in and try_new->try. And those are keywords.

We prefer to keep new_ in the names as originally implemented and approved by the FCP.

[dtolnay]

@bors r+

[bors]

:pushpin: Commit ae88be497c7bdbf4384a45cbf1c504bef0d7704f has been approved by dtolnay

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- https://github.com/rust-lang/rust/pull/129663#issuecomment-2313062457

[workingjubilee]

I need to bless the Miri tests, I guess...?

[workingjubilee]

Oh, no, new tests that use this feature, I see.

[workingjubilee]

@bors r=dtolnay,joboet

[bors]

:pushpin: Commit 605d9cf3b5f77f3f46d333347b21ab18697b75c6 has been approved by dtolnay,joboet

It is now in the queue for this repository.

[RalfJung]

@rust-lang/release shouldn't there be a relnotes tracking issue for this? I can't find one.

[workingjubilee]

Fixed.