stabilize core parts of MaybeUninit #60445
Conversation
|
r? @Kimundi (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @Centril |
Centril
added
T-lang
This comment has been minimized.
This comment has been minimized.
| #[inline] | ||
| #[rustc_deprecated(since = "2.0.0", reason = "use `mem::MaybeUninit::uninit` instead")] | ||
| #[rustc_deprecated(since = "1.40.0", reason = "use `mem::MaybeUninit` instead")] |
There was a problem hiding this comment.
This function is widely used so I figured we'd give it some time.
There was a problem hiding this comment.
I would suggest 1.38 instead as a middle ground. 1.34.0 seems rather long (~6 months from 1.36).
There was a problem hiding this comment.
The precedent with #52994 is to keep it future-deprecated for 3 releases, that would be 1.39.
Stabilization proposalI propose that we stabilize the following API: #[derive(Copy)]
pub union MaybeUninit<T> {
uninit: (),
value: ManuallyDrop<T>,
}
impl<T: Copy> Clone for MaybeUninit<T> { ... }
impl<T> MaybeUninit<T> {
pub const fn new(val: T) -> MaybeUninit<T> { ... }
pub const fn uninit() -> MaybeUninit<T> { ... }
pub fn zeroed() -> MaybeUninit<T> { ... }
pub fn as_ptr(&self) -> *const T { ... }
pub fn as_mut_ptr(&mut self) -> *mut T { ... }
pub unsafe fn assume_init(self) -> T { ... }
}The proposed interface is minimal yet still useful as noted in the PR description:
As the description notes, the API has also been tested inside the standard library and elsewhere. The name of the type, The documentation for A further note: rust-lang/rfcs#2582 has not been accepted yet and therefore we leave in place a warning in the documentation for anyone that tries to rely on those semantics with current surface syntax. Or as the PR description notes:
As for the deprecation of With all that said: @rfcbot merge |
|
Team member @Centril 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
added
proposed-final-comment-period
|
Is there a crater run on how much of the ecosystem currently uses |
|
@withoutboats I don't believe so. |
|
We discussed this briefly on the lang team meeting. Mainly, the subject was the deprecation schedule. We agreed that clear communication was important. We should also try to do a crater run to see when deprecation is most opportune. However, (in my personal view) we can stabilize and tweak the deprecation date later based on data. |
|
@bors r=Centril |
|
📌 Commit 1916391 has been approved by |
bors
added
S-waiting-on-bors
|
@bors p=1 |
|
⌛ Testing commit 1916391 with merge 6dabc5d1c3298e8fede2f41503d30e27e48e6236... |
|
@bors retry Yielding priority to the stable release. |
|
@pietroalbini By the way, https://github.com/rust-lang/rust/blob/beta/src/bootstrap/channel.rs mentioning 1.35 suggests that 1.36 beta has not been cut yet, is that right? It’d be nice if this PR can make it in. |
|
The process says "Promote master to beta (T-2 days, Tuesday)", so I take it if we can land this today we are good? That was the expectation anyways. ;) |
|
@bors p=50 |
|
@SimonSapin yep, beta will be cut tomorrow. I'll try to remember to check this PR before cutting it. |
stabilize core parts of MaybeUninit and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing rust-lang/rfcs#1892. Also expand the documentation a bit. This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in `BTreeMap` (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for `SmallVec` (Cc @bluss). Making this useful for structs requires rust-lang/rfcs#2582 or a commitment that references to uninitialized data are not insta-UB.
|
☀️ Test successful - checks-travis, status-appveyor |
adjust deprecation date of mem::uninitialized In rust-lang#60445 we [decided](rust-lang#60445 (comment)) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
adjust deprecation date of mem::uninitialized In rust-lang#60445 we [decided](rust-lang#60445 (comment)) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
adjust deprecation date of mem::uninitialized In rust-lang#60445 we [decided](rust-lang#60445 (comment)) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
adjust deprecation date of mem::uninitialized In rust-lang#60445 we [decided](rust-lang#60445 (comment)) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
adjust deprecation date of mem::uninitialized In rust-lang#60445 we [decided](rust-lang#60445 (comment)) that we'd deprecate for 1.38 instead of 1.40, but I forgot to adjust for that.
For stabalisation of `MaybeUninit` cf. rust-lang/rust#60445
- Fix clippy lints - Bump minimum Rust version beyond Rocket required for - `std::mem::MaybeUninit` (cf. rust-lang/rust#60445) - `alloc` crate
- Fix clippy lints - Bump minimum Rust version beyond Rocket required for - `std::mem::MaybeUninit` (cf. rust-lang/rust#60445) - `alloc` crate
and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing rust-lang/rfcs#1892.
Also expand the documentation a bit.
This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in
BTreeMap(with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough forSmallVec(Cc @bluss).Making this useful for structs requires rust-lang/rfcs#2582 or a commitment that references to uninitialized data are not insta-UB.