Stabilize most common subset of alloc_layout_extras

[CAD97]

Tracking issue: #55724

Specifically, this stabilizes:

pub fn Layout::align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::pad_to_align(&self) -> Layout;
pub fn Layout::extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::array<T>(n: usize) -> Result<Layout, LayoutErr>;

Methods that are tracked by #55724 but are not stabilized here:

pub fn Layout::padding_needed_for(&self, align: usize) -> usize;
pub fn Layout::repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;

Combined, these stabilized functions allow code to construct and manipulate repr(C) layouts while letting the standard library handle correctness in the face of edge cases. For example use cases, consider the usage in hashbrown, crossbeam-skiplist, pointer-utils/slice-dst, and of course the standard library itself.

Providing a higher-level API such as Layout::repr_c<const N: usize>(fields: [Layout; N]) -> Result<(Layout, [usize; N]), LayoutErr> is blocked on const generics, which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal, as the reason for calculating the layout like this rather than Layout::new is to get the field offsets.

The primary issue with the current API is having to call .pad_to_align() to match the layout of a repr(C) struct. However, I think this is not just a (failing? limitation?) of the API, but rather intrinsic complexity. While all Rust-defined types have size==stride, and probably will for the foreseeable future, there is no inherent reason why this is a limitation of all allocations. As such, the Layout manipulation APIs shouldn't impose this limitation, and instead the higher level api of repr_c (or just plain old using Layout::new) can make keeping it simple.

cc @matklad r? @rust-lang/libs

[CAD97]

whoops I broke highfive by r-ing a team, so rng says...

r? @dtolnay

[Amanieu]

I would like Layout::repeat to be stabilized as well, it is a very common operation when dealing with complex allocations.

[CAD97]

Personally, I'm not comfortable making the call on whether repeat is correctly specified or not. @Mooli brought up that repeat includes trailing padding, which is arguably not necessary.

In another formulation, layout.repeat(n) produces a distinct result from calling extend multiple times. I've actually added an unnecessary-with-current-repeat pad_to_align call to array here (which, in hindsight, is probably not necessary even with a weaker repeat that doesn't provide trailing padding because size==stride).

I don't feel confident calling for the stabilization of repeat without addressing the difference between repeat and multiple calls to extend, whereas the four I've called for here are much more obviously correct.

[Amanieu]

Fair enough, let's defer on repeat for now then.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @KodrAus
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

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.

[CAD97]

Amended to refer to a 1.44 stabilization in the attributes.

[bors]

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

[Amanieu]

ping @sfackler @KodrAus @withoutboats for checkboxes.

[Amanieu]

ping @sfackler @KodrAus @withoutboats for checkboxes.

[CAD97]

Rebased.

[Amanieu]

(I went ahead and checked for @KodrAus since he's busy)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[Amanieu]

r=me after fixing the doc comments.

[Amanieu]

@bors r+

[bors]

📌 Commit 98f0a82 has been approved by Amanieu