r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

Once builtin# syntax is merged, would it make sense to implement builtin#ptr_write, as suggested in #108516 (comment) ?

@clubby789 personally I'd like that, yes. It is imo better to have such a primitive than #[rustc_box], as its main use is inside the vec![] macro which immediately converts the boxed slice into a Vec. Outside of rust, builtin#write (and its macro wrapper) can support users who don't have alloc or std but do have core, say rust-on-linux folks. The offset_of macro btw helps people with these use cases as well because it makes it easier for them to build macros that get you 95% there... but all of this obviously doesn't change the fact that one can't remove builtin#write/#[rustc_box] from vec![]'s implementation and IMO it's simpler to have builtin#write than to have #[rustc_box].

It might be better to have a builtin#shallow_init_box instead to more closely match the mir that #[rustc_box] generates.

Oh I was unaware of rust-lang/compiler-team#460 and #89030 . It seems to be a special case just to support box syntax / #[rustc_box]. Maybe it would be possible to use something that builds on MaybeUninit instead, say for example Box::new_uninit_slice? IIRC the magic that avoids the copies onto the stack is inside the expr_into_dest stuff to write into the Box pointer, not the stuff before it.

Unwinding seems to be implemented weirdly, order depending on whether there is a panic call or not:

struct LoudDrop(u8);

impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("dropping {}", self.0);
    }
}
fn main() {
    {
        let _v = vec!(LoudDrop(0), LoudDrop(1));
    }
    println!("Hi");
    {
        let _v = vec!(LoudDrop(2), LoudDrop(3), LoudDrop(4), panic!());
    }
}

prints

dropping 0
dropping 1
Hi
dropping 4
dropping 3
dropping 2

anyways we should better discuss this in a separate thread, I want to keep this one dedicated to my PR. Edit: filed #110715

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

#110970 has landed, r=me after rebase.
@rustbot author

@rustbot ready

@bors r+

Commit d5669bf has been approved by petrochenkov

It is now in the queue for this repository.

@bors r+

Commit 83b4df4 has been approved by petrochenkov

It is now in the queue for this repository.