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

Implementation: #...
- honestly have no idea
- related API was added in Tracking issue for uninitialized constructors for Box, Rc, Arc #63291
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]>

workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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

88 tasks

lolbinarycat added the F-box_uninit_write label Sep 3, 2024

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

Loading

Tracking Issue for box_uninit_write #129397

Tracking Issue for box_uninit_write #129397

Comments

workingjubilee commented Aug 22, 2024 • edited Loading

Public API

Steps / History

Unresolved Questions

Footnotes

Tracking Issue for `box_uninit_write` #129397

Tracking Issue for `box_uninit_write` #129397

workingjubilee commented Aug 22, 2024 •

edited

Loading