-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Stabilize and re-export core::array in std #60657
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
Looks good, thanks! @bors r+ |
📌 Commit 028e78d has been approved by |
…apin Stabilize and re-export core::array in std Fixes rust-lang#60014
Rollup of 5 pull requests Successful merges: - #60601 (Add a `cast` method to raw pointers.) - #60638 (pin: make the to-module link more visible) - #60647 (cleanup: Remove `DefIndexAddressSpace`) - #60656 (Inline some Cursor calls for slices) - #60657 (Stabilize and re-export core::array in std) Failed merges: r? @ghost
You're missing some changes in the |
@jethrogb Thank you for pointing out, what I should do is to add |
Well, features need to be added at the root of the crate, which you could do conditionally depending on the target (there's already a list for SGX). However, I haven't looked at this PR in detail, but since you're stabilizing, I'd image it's just a matter of changing to code to use the stable API instead? |
Oh, I missed it, |
No, |
I think you might get a warning about an unused feature now on non-SGX platforms (but I'm not sure). |
I think your PR might be merged at 028e78d because the failure only happens when compiling with |
So it turns out if you push to your branch while bors is testing it in a rollup is a bad idea ;) I think this PR can be closed. I've filed #60684 for the SGX failure |
Oops, sorry... I'll close this. |
Fix cfg(test) build on SGX Introduced in #60657 r? @joshtriplett
library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
Rollup merge of rust-lang#132482 - lukas-code:stab-attrs, r=Noratrieb library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
Fixes #60014