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

Tracking issue for uninitialized constructors for Box, Rc, Arc #63291

Open
SimonSapin opened this issue Aug 5, 2019 · 52 comments
Open

Tracking issue for uninitialized constructors for Box, Rc, Arc #63291

SimonSapin opened this issue Aug 5, 2019 · 52 comments
Labels
A-raw-pointers Area: raw pointers, MaybeUninit, NonNull B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@SimonSapin
Copy link
Contributor

SimonSapin commented Aug 5, 2019

Assigning MaybeUninit::<Foo>::uninit() to a local variable is usually free, even when size_of::<Foo>() is large. However, passing it for example to Arc::new causes at least one copy (from the stack to the newly allocated heap memory) even though there is no meaningful data. It is theoretically possible that a Sufficiently Advanced Compiler could optimize this copy away, but this is reportedly unlikely to happen soon in LLVM.

This issue tracks constructors for containers (Box, Rc, Arc) of MaybeUninit<T> or [MaybeUninit<T>] that do not initialized the data, and unsafe conversions to the known-initialized types (without MaybeUninit). The constructors are guaranteed not to make unnecessary copies.

PR #62451 adds:

impl<T> Box<T> { pub fn new_uninit() -> Box<MaybeUninit<T>> {} }
impl<T> Box<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Box<T> {} }
impl<T> Box<[T]> { pub fn new_uninit_slice(len: usize) -> Box<[MaybeUninit<T>]> {} }
impl<T> Box<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Box<[T]> {} }

impl<T> Rc<T> { pub fn new_uninit() -> Rc<MaybeUninit<T>> {} }
impl<T> Rc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Rc<T> {} }
impl<T> Rc<[T]> { pub fn new_uninit_slice(len: usize) -> Rc<[MaybeUninit<T>]> {} }
impl<T> Rc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Rc<[T]> {} }

impl<T> Arc<T> { pub fn new_uninit() -> Arc<MaybeUninit<T>> {} }
impl<T> Arc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Arc<T> {} }
impl<T> Arc<[T]> { pub fn new_uninit_slice(len: usize) -> Arc<[MaybeUninit<T>]> {} }
impl<T> Arc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Arc<[T]> {} }

PR #66128 adds:

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

Unresolved question:

  • The constructor that returns for example Box<MaybeUninit<T>> might “belong” more as an associated function of that same type, rather than Box<T>. (And similarly for other constructors.) However this would make a call like Box::<u32>::new_uninit() becomes Box::<MaybeUnint<u32>>::new_uninit() which feels unnecessarily verbose. I suspect that this turbofish will be needed in a lot of cases to appease type inference.
@SimonSapin SimonSapin added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Aug 5, 2019
@Centril Centril added the requires-nightly This issue requires a nightly compiler in some way. label Aug 5, 2019
@TimDiekmann
Copy link
Member

TimDiekmann commented Oct 5, 2019

Just from looking at the current source code:

pub fn new_uninit() -> Box<mem::MaybeUninit<T>> {
    let layout = alloc::Layout::new::<mem::MaybeUninit<T>>();
    let ptr = unsafe {
        Global.alloc(layout)
            .unwrap_or_else(|_| alloc::handle_alloc_error(layout))
    };
    Box(ptr.cast().into())
}

When mem::size_of::<T>() == 0, a zero-sized layout is passed to Global.alloc but alloc mentions:

This function is unsafe because undefined behavior can result if the caller does not ensure that layout has non-zero size.

Did I have overseen something or is this a bug?

@SimonSapin
Copy link
Contributor Author

Good point! I copied this pattern from Rc and Arc, but there the header (refcounts) cause the allocation to never be zero-size.

Box::new_uninit_slice has a similar bug with size_of() == 0 or len == 0.

@TimDiekmann
Copy link
Member

TimDiekmann commented Oct 5, 2019

I have noticed this when implementing Box for custom allocators with non-zero layouts. Turns out, that this is indeed useful 🙂

This is my implementation for the sliced version.

SimonSapin added a commit to SimonSapin/rust that referenced this issue Oct 6, 2019
Requesting a zero-size allocation is not allowed,
return a dangling pointer instead.

CC rust-lang#63291 (comment)
@SimonSapin
Copy link
Contributor Author

#65174

Centril added a commit to Centril/rust that referenced this issue Oct 16, 2019
Fix zero-size uninitialized boxes

Requesting a zero-size allocation is not allowed, return a dangling pointer instead.

CC rust-lang#63291 (comment)
Centril added a commit to Centril/rust that referenced this issue Oct 19, 2019
Fix zero-size uninitialized boxes

Requesting a zero-size allocation is not allowed, return a dangling pointer instead.

CC rust-lang#63291 (comment)
Centril added a commit to Centril/rust that referenced this issue Oct 19, 2019
Fix zero-size uninitialized boxes

Requesting a zero-size allocation is not allowed, return a dangling pointer instead.

CC rust-lang#63291 (comment)
Centril added a commit to Centril/rust that referenced this issue Oct 19, 2019
Fix zero-size uninitialized boxes

Requesting a zero-size allocation is not allowed, return a dangling pointer instead.

CC rust-lang#63291 (comment)
tmandry added a commit to tmandry/rust that referenced this issue Nov 26, 2019
alloc: Add new_zeroed() versions like new_uninit().

MaybeUninit has both uninit() and zeroed(), it seems reasonable to have the same
surface on Box/Rc/Arc.

Needs tests.

cc rust-lang#63291
@Kixunil
Copy link
Contributor

Kixunil commented Dec 13, 2019

What are the requirements for stabilizing the Box API?

I don't think using Rc<MaybeUninit<T>> (and Arc) is currently that useful, as Arc happens to be shared (no mutation). However, there's this pattern where one wants to create a value while it's uniquely owned and then share it later. Doing it with Box would mean copying, so I was thinking about having RcMut and ArcMut that work exactly as Box, but reserve space for reference counters, so that when you call share() on them, they just initialize ref count and convert to Rc/Arc. This is however another topic. Did anyone had this idea before or should I start discussion somewhere?

@SimonSapin
Copy link
Contributor Author

there's this pattern where one wants to create a value while it's uniquely owned and then share it later

Yes, that’s exactly the idea with having Rc::new_uninit together with Rc::get_mut_unchecked #63292. It would also work with Rc::new_uninit + Rc::get_mut + unwrap, with an unnecessary run-time check (assuming sharing only after this).

@Kixunil
Copy link
Contributor

Kixunil commented Dec 16, 2019

Great! I still think it'd be better to provide safe abstraction for it, but at least it'd be possible to do in a library.

@rickvanprim
Copy link

Similar to new_zeroed() it would be nice to have a new_zeroed_slice().

@josephlr
Copy link
Contributor

Okay, so there is no way to create an array on heap with some length in stable Rust, even in unsafe? -_-"

It is possible to create a zeroed array or slice directly on the heap on Stable Rust and without using unsafe:

const N: usize = 4096*4096;

pub fn make_array() -> Box<[u8; N]> {
    vec![0; N].into_boxed_slice().try_into().unwrap()
}

pub fn make_slice(n: usize) -> Box<[u8]> {
    vec![0; n].into_boxed_slice()
}

This doesn't blow the stack even with opt-level=0.

@SimonSapin
Copy link
Contributor Author

That’s an optimization (based on specialization of a private trait) in current versions of the standard library, but it only works for some types and is not a documented guarantee.

@QuineDot
Copy link

Regarding the self parameter, using some_box_maybe_uninit.assume_init() currently resolves to MaybeUninit::assume_init, though it at least also triggers 48919. Stabilizing the method with the self receiver will be a breaking change as the return types differ.

@thomcc
Copy link
Member

thomcc commented Jan 23, 2023

and is not a documented guarantee.

This is correct, but it's also true that we'd probably need a very good reason to regress it. If some code's correctness (somehow) relies on this, they should find another method, but for performance reasons I think it's safe enough to rely on.

That said, as you point out it does not work for all types.

fbq pushed a commit to fbq/linux that referenced this issue Mar 11, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

See [1] [2] [3] for background information.

[1] Rust-for-Linux/linux#879
[2] Rust-for-Linux/linux#2
[3] rust-lang/rust#63291

Signed-off-by: Asahi Lina <lina@asahilina.net>
fbq pushed a commit to fbq/linux that referenced this issue Apr 4, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

See [1] [2] [3] for background information.

[1] Rust-for-Linux/linux#879
[2] Rust-for-Linux/linux#2
[3] rust-lang/rust#63291

Signed-off-by: Asahi Lina <lina@asahilina.net>
ojeda pushed a commit to ojeda/linux that referenced this issue Apr 9, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

See [1] [2] [3] for background information.

[1] Rust-for-Linux#879
[2] Rust-for-Linux#2
[3] rust-lang/rust#63291

Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda pushed a commit to Rust-for-Linux/linux that referenced this issue Apr 10, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: #879
Link: #2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[Reworded to use `Link` tags]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda pushed a commit to Rust-for-Linux/linux that referenced this issue Apr 10, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: #879
Link: #2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
asahilina added a commit to AsahiLinux/linux that referenced this issue Apr 28, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux#879
Link: Rust-for-Linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
@safinaskar
Copy link
Contributor

safinaskar commented May 29, 2023

API looks very strange. Box::new_uninit returns type, which is different from type this method lives in! new_uninit is located in Box<T>, but returns Box<MaybeUninit<T>>. This is absolute violation of principle of least surprise. I just have read #110715 (comment) and I initially was unable to understand the code. I wondered how Box::<Type>::new_uninit() can possibly work. Then I opened docs and then I was able to understand what is going on.

So, please make signature so:

impl<T> Box<MaybeUninit<T>, Global> {
  fn new_uninit() -> Box<MaybeUninit<T>, Global> { ... }
}

The same applies to other functions, for example, try_new_uninit

Kaz205 pushed a commit to Kaz205/linux that referenced this issue May 30, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux#879
Link: Rust-for-Linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jun 9, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jun 16, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jun 21, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jun 29, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jul 2, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jul 5, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
herrnst pushed a commit to herrnst/linux-asahi that referenced this issue Jul 12, 2023
The unstable new_uninit feature enables various library APIs to create
uninitialized containers, such as `Box::assume_init()`. This is
necessary to build abstractions that directly initialize memory at the
target location, instead of doing copies through the stack.

Will be used by the DRM scheduler abstraction in the kernel crate, and
by field-wise initialization (e.g. using `place!()` or a future
replacement macro which may itself live in `kernel`) in driver crates.

Link: Rust-for-Linux/linux#879
Link: Rust-for-Linux/linux#2
Link: rust-lang/rust#63291
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Link: https://lore.kernel.org/r/20230224-rust-new_uninit-v1-1-c951443d9e26@asahilina.net
[ Reworded to use `Link` tags. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
@bertptrs
Copy link
Contributor

Regarding the self parameter, using some_box_maybe_uninit.assume_init() currently resolves to MaybeUninit::assume_init, though it at least also triggers 48919. Stabilizing the method with the self receiver will be a breaking change as the return types differ.

This could be resolved by not making Box::assume_init a method but rather an associated function like most of the Rc API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-raw-pointers Area: raw pointers, MaybeUninit, NonNull B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests