Add tracking issue for Layout methods (and some API changes)

[Amanieu]

These methods are already useful when used with the stable global allocator API (stabilized in #51241).

pubfnalign_to(&self,align:usize) -> Result<Layout,LayoutErr>;pubfnpadding_needed_for(&self,align:usize) -> usize;pubfnrepeat(&self,n:usize) -> Result<(Layout,usize),LayoutErr>;pubfnextend(&self,next:Layout) -> Result<(Layout,usize),LayoutErr>;pubfnrepeat_packed(&self,n:usize) -> Result<Layout,LayoutErr>;pubfnextend_packed(&self,next:Layout) -> Result<Layout,LayoutErr>;pubfnarray<T>(n:usize) -> Result<Layout,LayoutErr>;

cc #32838

r? @SimonSapin

[SimonSapin]

repeat and extend’s Ok return type is (Layout, usize), where the usize is an offset.

extend_packed does the same, with docs saying:

(The offset is always the same as self.size(); we use this signature out of convenience in matching the signature of extend.)

… but repeat_packed doesn’t, its Ok return type is just Layout.

This seems inconsistent for no reason, should we change extend_packed or repeat_packed to have the other’s return type?

[SimonSapin]

@rfcbot fcp merge

[rfcbot]

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

• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• compat with repr(C) resolved by Add tracking issue for Layout methods (and some API changes) #55366 (comment)
• not-ready-yet (Add tracking issue for Layout methods (and some API changes) #55366 (comment))
• return types consistency (Add tracking issue for Layout methods (and some API changes) #55366 (comment))

Once a majority of reviewers approve (and none object), 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.

[SimonSapin]

@rfcbot concern return types consistency

For #55366 (comment)

[SimonSapin]

@rfcbot concern compat with repr(C)

For example:

#[repr(C)]structPair<A,B>{a:A,b:B,}assert_eq!(Layout::new::<Pair<Foo,Bar>>(),Layout::new::<Foo>().extend(Layout::new::<Bar>()))

Does this hold for any types Foo and Bar? Do we want to guarantee it’ll always hold? If so, let’s document that guarantee.

Similarly for repr(C, packed) and extend_packed.

Note that Layout::array is already documented as compatible with [T; n].

[Centril]

Does this hold for any types Foo and Bar? Do we want to guarantee it’ll always hold? If so, let’s document that guarantee.

Similarly for repr(C, packed) and extend_packed.

cc @rust-lang/lang

[Amanieu]

Does this hold for any types Foo and Bar? Do we want to guarantee it’ll always hold? If so, let’s document that guarantee.

Yes this will always hold because the behavior of extend (pad to alignment of 2nd type, then add size) happens to match the way C struct layout rules work.

[SimonSapin]

I suspected that but wasn’t sure how C struct layout is defined. Could you add sentence or two about this in the doc-comments of the relevant methods?

[Amanieu]

This seems inconsistent for no reason, should we change extend_packed or repeat_packed to have the other’s return type?

I feel that we definitely need to change something. My preference would be to changeextend_packed to just return a plain Layout for its Ok. I don't think that we gain anything by returning tuple, since I don't see people switching between the normal and packed layouts on a whim.

[SimonSapin]

@Amanieu I personally agree with changing extern_packed to return Layout without a tuple.

@rust-lang/libs Any thoughts on the API change proposed above?

@rfcbot resolve compat with repr(C)

[alexcrichton]

I'm personally a bit wary to simply stabilize everything as-is as these afaik haven't gone through a great deal of review. I'd rather stabilize methods which have use cases today and have clearly defined signatures and such. For example this PR doesn't itself include motivation (or links to) for stabilization, what's the main use case for stabilizing all of these methods?

Some thoughts I have on these methods:

• align_to contains an unwrap but doesn't return a Result? (although documented, seems inconsistent with array for example)
• The usize return value with offsets seems a little odd to me, is that a value that's really going to be stored at runtime somewhere and then later looked up to actually access values? Otherwise, what's the use case of usize return value being returned? (curious to see if we can cook up an example or something like that)
• I think the array method makes the most sense to me about how it'd be used!

I'm personally would prefer to lean on the side of being conservative due to how low level these are. I'd be fine changing signatures so long as we have good reasons as well!

[Amanieu]

The main use case is to construct complex allocation layouts for use with the stable global allocator API. For example:

• std::collections::HashMap
• hashbrown
• Not exactly an example of use, but it would be very useful in crossbeam-skiplist

[Amanieu]

Regarding align_to, I agree with you, this should probably be changed to return a Result like the other Layout methods.

[SimonSapin]

these afaik haven't gone through a great deal of review

It sounds like we’re on a good start to do the review in this thread :) And if we’re still unsure about some some methods we can leave them for now and stabilize the rest.

The usize return value with offsets seems a little odd to me, is that a value that's really going to be stored at runtime somewhere and then later looked up to actually access values?

I’d expect the offsets not to be stored. (Growing HashMap by a couple usizes for example would be non-trivial cost.) Instead they can be re-computed every time they’re needed. Since size_of::<T>() is constant after monomorphization, much of a that computation can be constant-folded by the optimizer.

[alexcrichton]

I suppose I'm not really comfortable myself proposing stablization without motivation mentioned in the description and also doing an API review at the same time.

The align_to and array methods I think are probably fine to stabilize (with returning a result from align_to). The others have the uncomfortable usize return value and also seem largely less motivated other than extend perhaps.

Is there a way perhaps the usize return value could be tweaked to be more obvious or communicated via a different means?

[Amanieu]

@alexcrichton I personally feel that the extend method is also important to stabilize, with the usize parameter. In both places where it is currently used (hashbrown and std::collections::HashMap) this is used to effectively allocate 2 separate arrays with a single call to the allocator. The offset is used to get the start address of the 2nd array after the allocation.

For std::collections::HashMap, the offset to the data array is re-calculated every time a method is called. For hashbrown, a separate data pointer is used since it can be left dangling when the table is empty.

[alexcrichton]

Ok well at the very least, I would want to restrict a consideration of stabilization to only align_to, array, and extend. The padding_needed_for, repeat_packed, and extend_packed stabilizations seem over ambitious and largely "they were already there and why not stabilize".

I'm still not sure what to do about extend. I continue to be somewhat uncomfortable that this is only coming up now as stabilization is proposed to happen and the rationale is "I've used it here, it was convenient, let's stabilize it as-is".

[SimonSapin]

I think that extend is fundamental to the principle of having somwhat-high-level APIs for computing non-trivial layouts, rather than making users compute usize values then calling from_size_align.

padding_needed_for is not particularly useful ifextend exists.

I don’t know when *_packed would be used, but then the same applies to #[repr(packed)].

[Amanieu]

I agree with @SimonSapin here: extend is an extremely useful tool for manipulating layouts and the returned usize is also very useful when you want to pack multiple objects into a single allocation (to avoid multiple calls to the allocator).

For align_to, are we happy with is as it is or do we also want align_and_pad_to?

What are you thoughts on stabilizing repeat as well? I don't personally have a use for it, but it might fit well as a more general form of array. However I am less sure about the usize result on this one.

[alexcrichton]

FWIW these sorts of comments are what I would expect to be, for example, in the description of this PR, the description of an FCP to stabilize, etc. Right now these comments are buried in a discussion that is quite long at this point and hard to extract, but the comments provide good rationale for stabilizing these methods.

Procedurally I would prefer at this point if we open a dedicated tracking issue for the proposal to stabilize here. Such a tracking issue would contain rationale, use cases, etc, along with the proposed-to-be-stabilized interface. Other issues mentioning these APIs could then also get a comment indicating that this tracking issue is proposing stabilization of a few APIs.

I'm gonna go ahead and register a formal concern for this PR:

@rfcbot concern not-ready-yet

[Amanieu]

I have changed the PR to just split the Layout methods into a separate tracking issue (#55724).

[alexcrichton]

Thanks for the update! r=me but it looks like there's some minor build failures

@bors: delegate+

[bors]

✌️ @Amanieu can now approve this pull request

[Amanieu]

@bors: r+

[bors]

📌 Commit 02d50de has been approved by Amanieu

[bors]

⌛ Testing commit 02d50de with merge a22c88419fde9fd1845b994b4dcd4577e2f3bcfc...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job dist-armv7-linux of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:48:23] [RUSTC-TIMING] cc test:false 9.762
[00:48:24] [RUSTC-TIMING] rustc_llvm test:false 0.264
[00:49:46] error: linking with `armv7-unknown-linux-gnueabihf-gcc` failed: exit code: 1
[00:49:46] |
[00:49:46] = note: "armv7-unknown-linux-gnueabihf-gcc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.0.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.1.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.10.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.11.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.12.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.13.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.14.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.15.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.2.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.3.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.4.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.5.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.6.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.7.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.8.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.rustc_codegen_llvm.7g7og5aw-cgu.9.rcgu.o" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/librustc_codegen_llvm-12fd1f77ba91225a.so" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps/rustc_codegen_llvm-12fd1f77ba91225a.91rul2fexkx4aom.rcgu.o" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/release/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/armv7-unknown-linux-gnueabihf/release/build/rustc_llvm-aac0baade0920ba7/out" "-L" "/checkout/obj/build/armv7-unknown-linux-gnueabihf/llvm/build/lib" "-L" "/x-tools/armv7-unknown-linux-gnueabihf/lib/gcc/armv7-unknown-linux-gnueabihf/4.9.3/../../../../armv7-unknown-linux-gnueabihf/lib" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "/tmp/rustcR7jEmh/libmemmap-9e7f398a2bab09fc.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustcR7jEmh/libtempfile-8857a588977f5d15.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustcR7jEmh/libremove_dir_all-b60c2a9c57e60641.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustcR7jEmh/libcc-c262071c6c930a28.rlib" "-Wl,--no-whole-archive" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-Wl,-Bdynamic" "-lrustc_codegen_utils-8129f5a8165a7d32" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_metadata-02c175333af1e118" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lsyntax_ext-c54fc1bbd7c9af9e" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_platform_intrinsics-60369a3d8db2d86c" "-Wl,-Bstatic" "-Wl,--whole-archive" "/tmp/rustcR7jEmh/librustc_llvm-d4cdbbee8c4a2fa6.rlib" "-Wl,--no-whole-archive" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-Wl,-Bdynamic" "-lrustc_incremental-bb928f5e81c2f845" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_allocator-c7828fd32ef4ea52" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_mir-87da6fd719cac671" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc-7476eefed5ab4758" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-ltest-52498e354d6ecf8d" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lterm-b0eea3b5873aacff" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_fs_util-c17f42ff706d3a0c" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lproc_macro-ae0b91eacd04d8f0" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lsyntax-f71e25cdd1b4172d" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_errors-d9e6559f0d98739a" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lsyntax_pos-334b67f4d4dc47ed" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_target-099a5048e5ae647c" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lfmt_macros-d5eb445cf0dc5fc5" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-larena-bafa97bf377a1cca" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_data_structures-0b5853f722bceaab" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lrustc_cratesio_shim-997ffd7d24de76bd" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lgraphviz-5400da503eb29b8f" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lserialize-b631c411369d7a44" "-Wl,--start-group" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/armv7-unknown-linux-gnueabihf/lib" "-lstd-f001e17a07b998b6" "-Wl,--end-group" "-Wl,-Bstatic" "/tmp/rustcR7jEmh/libcompiler_builtins-fc6b7f30f597aba7.rlib" "-Wl,-Bdynamic" "-lutil" "-lutil" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil" "-shared" "-Wl,-rpath,$ORIGIN/../lib"
[00:49:46] = note: /tmp/rustcR7jEmh/librustc_llvm-d4cdbbee8c4a2fa6.rlib(DCE.cpp.o): In function `(anonymous namespace)::DeadInstElimination::getAnalysisUsage(llvm::AnalysisUsage&) const':
[00:49:46] DCE.cpp:(.text._ZNK12_GLOBAL__N_119DeadInstElimination16getAnalysisUsageERN4llvm13AnalysisUsageE+0x2): relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `llvm::AnalysisUsage::setPreservesCFG()' defined in .text._ZN4llvm13AnalysisUsage15setPreservesCFGEv section in /tmp/rustcR7jEmh/librustc_llvm-d4cdbbee8c4a2fa6.rlib(Pass.cpp.o)
[00:49:46] [00:49:46] [00:49:46] error: aborting due to previous error
[00:49:46] ---
[00:49:46] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap dist --host armv7-unknown-linux-gnueabihf --target armv7-unknown-linux-gnueabihf
[00:49:46] Build completed unsuccessfully in 0:46:22
[00:49:46] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "rustc" "--target" "armv7-unknown-linux-gnueabihf" "-j" "4" "--release" "--locked" "--color" "always" "--manifest-path" "/checkout/src/librustc_codegen_llvm/Cargo.toml" "--features" "" "--message-format" "json"
[00:49:46] expected success, got: exit code: 101
[00:49:46] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1101:9
travis_time:end:10341060:start=1541557806775491841,finish=1541560793858771045,duration=2987083279204
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 1.
travis_time:start:031fa56b
---
travis_time:end:0037d6e0:start=1541560794746627926,finish=1541560794755377417,duration=8749491
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1122dce0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:02b4fad5
travis_time:start:02b4fad5
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0a0a8935
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[Amanieu]

The failure seems to be unrelated to this PR?

@bors retry

[bors]

⌛ Testing commit 02d50de with merge 1d83455...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: Amanieu
Pushing 1d83455 to master...

[rust-highfive]

📣 Toolstate changed by #55366!

Tested on commit 1d83455.
Direct link to PR: #55366

💔 nomicon on windows: test-pass → test-fail (cc @frewsxcv@gankro, @rust-lang/infra).
💔 nomicon on linux: test-pass → test-fail (cc @frewsxcv@gankro, @rust-lang/infra).

[kennytm]

The nomicon failure:

[01:03:36] ---- /checkout/src/doc/nomicon/src/vec-final.md - The_Final_Code (line 3) stdout ----
[01:03:36] error[E0658]: use of unstable library feature 'alloc_layout_extra' (see issue #55724)
[01:03:36] --> /checkout/src/doc/nomicon/src/vec-final.md:36:40
[01:03:36] |
[01:03:36] 34 | let ptr = Global.alloc(Layout::array::<T>(1).unwrap());
[01:03:36] | ^^^^^^^^^^^^^^^^^^
[01:03:36] |
[01:03:36] = help: add #![feature(alloc_layout_extra)] to the crate attributes to enable
[01:03:36] [01:03:36] error[E0658]: use of unstable library feature 'alloc_layout_extra' (see issue #55724)
[01:03:36] --> /checkout/src/doc/nomicon/src/vec-final.md:42:42
[01:03:36] |
[01:03:36] 40 | Layout::array::<T>(self.cap).unwrap(),
[01:03:36] | ^^^^^^^^^^^^^^^^^^
[01:03:36] |
[01:03:36] = help: add #![feature(alloc_layout_extra)] to the crate attributes to enable
[01:03:36] [01:03:36] error[E0658]: use of unstable library feature 'alloc_layout_extra' (see issue #55724)
[01:03:36] --> /checkout/src/doc/nomicon/src/vec-final.md:43:42
[01:03:36] |
[01:03:36] 41 | Layout::array::<T>(new_cap).unwrap().size());
[01:03:36] | ^^^^^^^^^^^^^^^^^^
[01:03:36] |
[01:03:36] = help: add #![feature(alloc_layout_extra)] to the crate attributes to enable
[01:03:36] [01:03:36] error[E0658]: use of unstable library feature 'alloc_layout_extra' (see issue #55724)
[01:03:36] --> /checkout/src/doc/nomicon/src/vec-final.md:69:32
[01:03:36] |
[01:03:36] 67 | Layout::array::<T>(self.cap).unwrap());
[01:03:36] | ^^^^^^^^^^^^^^^^^^
[01:03:36] |
[01:03:36] = help: add #![feature(alloc_layout_extra)] to the crate attributes to enable