Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partially stabilize feature(new_uninit) #129401

Merged

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Aug 22, 2024

Finished comment period: #63291 (comment)

The following API has been stabilized from #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

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
Copy link
Collaborator

rustbot commented Aug 22, 2024

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 rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 22, 2024
@rustbot
Copy link
Collaborator

rustbot commented Aug 22, 2024

The Miri subtree was changed

cc @rust-lang/miri

@workingjubilee workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. relnotes Marks issues that should be documented in the release notes of the next release. labels Aug 22, 2024
@workingjubilee
Copy link
Member Author

workingjubilee commented Aug 22, 2024

This goes into the relnotes because:

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

@joboet
Copy link
Member

joboet commented Aug 22, 2024

@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.

@dtolnay dtolnay changed the title Partially initialize feature(new_uninit) Partially stabilize feature(new_uninit) Aug 22, 2024
@dtolnay dtolnay added I-libs-api-nominated Nominated for discussion during a libs-api team meeting. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 22, 2024
@workingjubilee workingjubilee force-pushed the partial-initialization-of-stabilization branch from b1d0371 to 3788955 Compare August 22, 2024 16:08
@bors
Copy link
Collaborator

bors commented Aug 25, 2024

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

@workingjubilee workingjubilee force-pushed the partial-initialization-of-stabilization branch from 3788955 to ae88be4 Compare August 26, 2024 04:25
@workingjubilee
Copy link
Member Author

@bors try

@bors
Copy link
Collaborator

bors commented Aug 26, 2024

⌛ Trying commit ae88be4 with merge b8a70e0...

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 26, 2024
…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
@bors
Copy link
Collaborator

bors commented Aug 26, 2024

☀️ Try build successful - checks-actions
Build commit: b8a70e0 (b8a70e08cf21cfc4847acd0f5f806ffeb5ea1620)

@dtolnay dtolnay assigned dtolnay and unassigned joboet Aug 27, 2024
@dtolnay
Copy link
Member

dtolnay commented Aug 27, 2024

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
Copy link
Member

dtolnay commented Aug 27, 2024

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 27, 2024

📌 Commit ae88be4 has been approved by dtolnay

It is now in the queue for this repository.

@workingjubilee
Copy link
Member Author

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

@workingjubilee workingjubilee force-pushed the partial-initialization-of-stabilization branch from ae88be4 to 605d9cf Compare August 27, 2024 17:19
@workingjubilee
Copy link
Member Author

@bors r=dtolnay,joboet

@bors
Copy link
Collaborator

bors commented Aug 27, 2024

📌 Commit 605d9cf has been approved by dtolnay,joboet

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 27, 2024
@workingjubilee workingjubilee removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Aug 27, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Aug 29, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 29, 2024
…kingjubilee

Rollup of 14 pull requests

Successful merges:

 - rust-lang#128192 (rustc_target: Add various aarch64 features)
 - rust-lang#129170 (Add an ability to convert between `Span` and `visit::Location`)
 - rust-lang#129343 (Emit specific message for time<=0.3.35)
 - rust-lang#129378 (Clean up cfg-gating of ProcessPrng extern)
 - rust-lang#129401 (Partially stabilize `feature(new_uninit)`)
 - rust-lang#129467 (derive(SmartPointer): assume pointee from the single generic and better error messages)
 - rust-lang#129494 (format code in tests/ui/threads-sendsync)
 - rust-lang#129617 (Update books)
 - rust-lang#129673 (Add fmt::Debug to sync::Weak<T, A>)
 - rust-lang#129683 (copysign with sign being a NaN can have non-portable results)
 - rust-lang#129689 (Move `'tcx` lifetime off of impl and onto methods for `CrateMetadataRef`)
 - rust-lang#129695 (Fix path to run clippy on rustdoc)
 - rust-lang#129712 (Correct trusty targets to be tier 3)
 - rust-lang#129715 (Update `compiler_builtins` to `0.1.123`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 9d5f794 into rust-lang:master Aug 29, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 29, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 29, 2024
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
@workingjubilee workingjubilee deleted the partial-initialization-of-stabilization branch August 29, 2024 21:11
ojeda added a commit to ojeda/linux that referenced this pull request Sep 4, 2024
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]>
ojeda added a commit to ojeda/linux that referenced this pull request Sep 4, 2024
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]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 4, 2024
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]>
ojeda added a commit to ojeda/linux that referenced this pull request Sep 4, 2024
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]>
ojeda added a commit to ojeda/linux that referenced this pull request Sep 4, 2024
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]>
ojeda added a commit to ojeda/linux that referenced this pull request Sep 4, 2024
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]>
ojeda added a commit to Rust-for-Linux/linux that referenced this pull request Sep 4, 2024
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]>
@RalfJung
Copy link
Member

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

@workingjubilee workingjubilee added relnotes Marks issues that should be documented in the release notes of the next release. and removed relnotes Marks issues that should be documented in the release notes of the next release. labels Sep 24, 2024
@workingjubilee
Copy link
Member Author

Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue for uninitialized constructors for Box, Rc, Arc
7 participants