Tracking Issue for `box_uninit_write` #129397

workingjubilee · 2024-08-22T05:42:04Z

Feature gate: #![feature(box_uninit_write)]

Split-out from #63291 as a result of stabilizing most of its API! It's a way to write to the MaybeUninit on the Box and thus initialize it!

Public API

impl<T, A> Box<MaybeUninit<T>, A> {
    pub fn write(mut boxed: Self, value: T) -> Box<T, A>;
}

Steps / History

Implement write() method for Box<MaybeUninit<T>> #88906
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

idk lol

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

The text was updated successfully, but these errors were encountered:

…n-of-stabilization, r=<try> Partially stabilize `feature(new_uninit)` Finished comment period: rust-lang#63291 (comment) The following API has been stabilized from rust-lang#63291 ```rust 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`: rust-lang#129396 - `box_uninit_write`: rust-lang#129397 All relevant code is thus either stabilized or split out of that issue, so this closes rust-lang#63291 as, with the FCP concluded, that issue has served its purpose. try-job: x86_64-rust-for-linux

Upstream Rust's libs-api team has consensus for stabilizing some of `feature(new_uninit)`, but not for `Box<MaybeUninit<T>>::write`. Instead, we can use `MaybeUninit<T>::write`, so Rust for Linux can drop the feature after stabilization. That will happen after merging, as the FCP has completed [1]. This is required before stabilization because remaining-unstable API will be divided into new features. This code doesn't know about those yet. It can't: they haven't landed, as the relevant PR is blocked on rustc's CI testing Rust-for-Linux without this patch. [ The PR has landed [2], so we could conditionally enable the new unstable feature (`box_uninit_write` [3]) instead, but just for a single `unsafe` block it is probably not worth it. For the time being, I added it to the "nice to have" section of our unstable features list. - Miguel ] Link: rust-lang/rust#63291 (comment) [1] Link: rust-lang/rust#129416 [2] Link: rust-lang/rust#129397 [3] Signed-off-by: Jubilee Young <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Trevor Gross <[email protected]> [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>

Upstream Rust's libs-api team has consensus for stabilizing some of `feature(new_uninit)`, but not for `Box<MaybeUninit<T>>::write`. Instead, we can use `MaybeUninit<T>::write`, so Rust for Linux can drop the feature after stabilization. That will happen after merging, as the FCP has completed [1]. This is required before stabilization because remaining-unstable API will be divided into new features. This code doesn't know about those yet. It can't: they haven't landed, as the relevant PR is blocked on rustc's CI testing Rust-for-Linux without this patch. [ The PR has landed [2] and will be released in Rust 1.82.0 (expected on 2024-10-17), so we could conditionally enable the new unstable feature (`box_uninit_write` [3]) instead, but just for a single `unsafe` block it is probably not worth it. For the time being, I added it to the "nice to have" section of our unstable features list. - Miguel ] Link: rust-lang/rust#63291 (comment) [1] Link: rust-lang/rust#129416 [2] Link: rust-lang/rust#129397 [3] Signed-off-by: Jubilee Young <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Trevor Gross <[email protected]> [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>

…ion-of-stabilization, r=dtolnay Partially stabilize `feature(new_uninit)` Finished comment period: rust-lang#63291 (comment) The following API has been stabilized from rust-lang#63291 ```rust 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`: rust-lang#129396 - `box_uninit_write`: rust-lang#129397 All relevant code is thus either stabilized or split out of that issue, so this closes rust-lang#63291 as, with the FCP concluded, that issue has served its purpose. try-job: x86_64-rust-for-linux

…ion-of-stabilization, r=dtolnay,joboet Partially stabilize `feature(new_uninit)` Finished comment period: rust-lang#63291 (comment) The following API has been stabilized from rust-lang#63291 ```rust 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`: rust-lang#129396 - `box_uninit_write`: rust-lang#129397 All relevant code is thus either stabilized or split out of that issue, so this closes rust-lang#63291 as, with the FCP concluded, that issue has served its purpose. try-job: x86_64-rust-for-linux

Rollup merge of rust-lang#129401 - workingjubilee:partial-initialization-of-stabilization, r=dtolnay,joboet Partially stabilize `feature(new_uninit)` Finished comment period: rust-lang#63291 (comment) The following API has been stabilized from rust-lang#63291 ```rust 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`: rust-lang#129396 - `box_uninit_write`: rust-lang#129397 All relevant code is thus either stabilized or split out of that issue, so this closes rust-lang#63291 as, with the FCP concluded, that issue has served its purpose. try-job: x86_64-rust-for-linux

…abilization, r=dtolnay,joboet Partially stabilize `feature(new_uninit)` Finished comment period: rust-lang/rust#63291 (comment) The following API has been stabilized from rust-lang/rust#63291 ```rust 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`: rust-lang/rust#129396 - `box_uninit_write`: rust-lang/rust#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

Like commit 0903b9e ("rust: alloc: eschew `Box<MaybeUninit<T>>::write`"), but for the new `rbtree` code. That is, `feature(new_uninit)` [1] got partially stabilized [2] for Rust 1.82.0 (expected to be released on 2024-10-17), but it did not include `Box<MaybeUninit<T>>::write`, which got split into `feature(box_uninit_write)` [3]. To avoid relying on a new unstable feature, rewrite the `write` + `assume_init` pair manually. Link: rust-lang/rust#63291 [1] Link: rust-lang/rust#129401 [2] Link: rust-lang/rust#129397 [3] Signed-off-by: Miguel Ojeda <[email protected]>

Like commit 0903b9e ("rust: alloc: eschew `Box<MaybeUninit<T>>::write`"), but for the new `rbtree` and `alloc` code. That is, `feature(new_uninit)` [1] got partially stabilized [2] for Rust 1.82.0 (expected to be released on 2024-10-17), but it did not include `Box<MaybeUninit<T>>::write`, which got split into `feature(box_uninit_write)` [3]. To avoid relying on a new unstable feature, rewrite the `write` + `assume_init` pair manually. Link: rust-lang/rust#63291 [1] Link: rust-lang/rust#129401 [2] Link: rust-lang/rust#129397 [3] Signed-off-by: Miguel Ojeda <[email protected]>

Like commit 0903b9e ("rust: alloc: eschew `Box<MaybeUninit<T>>::write`"), but for the new `rbtree` and `alloc` code. That is, `feature(new_uninit)` [1] got partially stabilized [2] for Rust 1.82.0 (expected to be released on 2024-10-17), but it did not include `Box<MaybeUninit<T>>::write`, which got split into `feature(box_uninit_write)` [3]. To avoid relying on a new unstable feature, rewrite the `write` + `assume_init` pair manually. Link: rust-lang/rust#63291 [1] Link: rust-lang/rust#129401 [2] Link: rust-lang/rust#129397 [3] Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Matt Gilbride <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

Upstream Rust's libs-api team has consensus for stabilizing some of `feature(new_uninit)`, but not for `Box<MaybeUninit<T>>::write`. Instead, we can use `MaybeUninit<T>::write`, so Rust for Linux can drop the feature after stabilization. That will happen after merging, as the FCP has completed [1]. This is required before stabilization because remaining-unstable API will be divided into new features. This code doesn't know about those yet. It can't: they haven't landed, as the relevant PR is blocked on rustc's CI testing Rust-for-Linux without this patch. [ The PR has landed [2] and will be released in Rust 1.82.0 (expected on 2024-10-17), so we could conditionally enable the new unstable feature (`box_uninit_write` [3]) instead, but just for a single `unsafe` block it is probably not worth it. For the time being, I added it to the "nice to have" section of our unstable features list. - Miguel ] Link: rust-lang/rust#63291 (comment) [1] Link: rust-lang/rust#129416 [2] Link: rust-lang/rust#129397 [3] Signed-off-by: Jubilee Young <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Trevor Gross <[email protected]> [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>

The CI is hitting errors and warnings now [1], due to Rust 1.82.0 being used to build an older Linux kernel: warning: the feature `new_uninit` has been stable since 1.82.0 and no longer requires an attribute to enable --> rust/kernel/lib.rs:17:12 | 17 | #![feature(new_uninit)] | ^^^^^^^^^^ | = note: `#[warn(stable_features)]` on by default error[E0658]: use of unstable library feature 'box_uninit_write' --> rust/kernel/alloc/box_ext.rs:25:12 | 25 | Ok(Box::write(b, x)) | ^^^^^^^^^^ | = note: see issue #129397 <rust-lang/rust#129397> for more information = help: add `#![feature(box_uninit_write)]` to the crate attributes to enable = note: this compiler was built on 2024-10-15; consider upgrading it if it is out of date Which is due to the current commit hash being from the Linux v6.10 cycle, when we did not yet support several Rust versions. Thus update the hash with a newer tag (the latest available) that does support several Rust versions, including the latest. In any case, updating is a good idea since it has been a while since we introduced Rust for Linux in the CI, and the intention is to update it from time to time nevertheless. Link: https://github.com/rust-lang/rust-bindgen/actions/runs/11637602211/job/32411071463?pr=2969#step:6:1362 [1] Signed-off-by: Miguel Ojeda <[email protected]>

safinaskar · 2025-02-06T00:55:25Z

@rustbot label A-box

scottmcm · 2025-02-12T19:28:15Z

Hi libs-api, I'd like to nominate this for stabilization consideration.

The API is simple: https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.write

pub fn write(boxed: Box<MaybeUninit<T>, A>, value: T) -> Box<T, A>

But it's particularly helpful in that it gives a safe way to do the "allocate first, then initialize" pattern with a Box for people who are concerned about large copies on the stack: instead of Box::new(foo()), they can Box::write(Box::new_uninit(), foo()).

It looks like it's not a method to avoid shadowing MaybeUninit::write, though I don't know how likely it is that people would want to do that instead of the move-the-box version. The non-method does make it slightly less discoverable.

An obvious alternative to stabilizing this would be to have some sort of Box::new_with(|| foo()) API, which could do the equivalent thing internally. Or maybe this gets caught up in the "there's too many constructors already and we wish there was a better way" that's soft-blocking some of the other constructors.

I do think this would be nice for more than just this case, though. Coupled with a Box<T> -> (T, Box<MaybeUninit<T>>) it'd give a safe way to reuse allocations, too.

Amanieu · 2025-02-18T16:21:38Z

@rfcbot merge

rfcbot · 2025-02-18T16:21:53Z

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2025-02-18T17:10:53Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2025-02-28T17:11:13Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

…heemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.

Rollup merge of rust-lang#137850 - slanterns:box_uninit_write, r=ibraheemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.

workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Aug 22, 2024

This was referenced Aug 22, 2024

Partially stabilize feature(new_uninit) #129401

Merged

library: Move unstable API of new_uninit to new features #129416

Merged

ojeda mentioned this issue Aug 24, 2024

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

90 tasks

lolbinarycat added the F-box_uninit_write label Sep 3, 2024

rustbot added the A-box Area: Our favorite opsem complication label Feb 6, 2025

scottmcm added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 12, 2025

Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 18, 2025

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 28, 2025

rfcbot added the to-announce Announce this issue on triage meeting label Feb 28, 2025

rustbot mentioned this issue Feb 28, 2025

Tracking issue for release notes of #129397: Tracking Issue for box_uninit_write #137810

Open

slanterns mentioned this issue Mar 1, 2025

Stabilize box_uninit_write #137850

Merged

jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 4, 2025

Rollup merge of rust-lang#137850 - slanterns:box_uninit_write, r=ibra…

32be95c

…heemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.

workingjubilee added a commit to workingjubilee/rustc that referenced this issue Mar 4, 2025

Rollup merge of rust-lang#137850 - slanterns:box_uninit_write, r=ibra…

7f2b73b

…heemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.

bors closed this as completed in 0bb2f95 Mar 5, 2025

rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 5, 2025

Unrolled build for rust-lang#137850

e6f0080

Rollup merge of rust-lang#137850 - slanterns:box_uninit_write, r=ibraheemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `box_uninit_write` #129397

Tracking Issue for `box_uninit_write` #129397

workingjubilee commented Aug 22, 2024 •

edited by dtolnay

Loading

safinaskar commented Feb 6, 2025

scottmcm commented Feb 12, 2025

Amanieu commented Feb 18, 2025

rfcbot commented Feb 18, 2025 •

edited by dtolnay

Loading

rfcbot commented Feb 18, 2025

rfcbot commented Feb 28, 2025

Tracking Issue for box_uninit_write #129397

Tracking Issue for box_uninit_write #129397

Comments

workingjubilee commented Aug 22, 2024 • edited by dtolnay Loading

Public API

Steps / History

Unresolved Questions

Footnotes

safinaskar commented Feb 6, 2025

scottmcm commented Feb 12, 2025

Amanieu commented Feb 18, 2025

rfcbot commented Feb 18, 2025 • edited by dtolnay Loading

rfcbot commented Feb 18, 2025

rfcbot commented Feb 28, 2025

Tracking Issue for `box_uninit_write` #129397

Tracking Issue for `box_uninit_write` #129397

workingjubilee commented Aug 22, 2024 •

edited by dtolnay

Loading

rfcbot commented Feb 18, 2025 •

edited by dtolnay

Loading