Skip to content

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

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

Stabilize and re-export core::array in std #60657

wants to merge 2 commits into from

Conversation

JohnTitor
Copy link
Member

Fixes #60014

@rust-highfive
Copy link
Contributor

r? @cramertj

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 9, 2019
Centril
Centril reviewed May 9, 2019
View reviewed changes
@Centril Centril added the relnotes Marks issues that should be documented in the release notes of the next release. label May 9, 2019
@Centril Centril added this to the 1.36 milestone May 9, 2019
@Centril Centril added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 9, 2019
@SimonSapin
Copy link
Contributor

Looks good, thanks!

@bors r+

@bors
Copy link
Collaborator

bors commented May 9, 2019

📌 Commit 028e78d has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 9, 2019
Centril added a commit to Centril/rust that referenced this pull request May 9, 2019
@Centril
Rollup merge of rust-lang#60657 - JohnTitor:stabilize-array, r=SimonS…
e40f9a6 
…apin

Stabilize and re-export core::array in std

Fixes rust-lang#60014
@Centril Centril mentioned this pull request May 9, 2019
Merged
bors added a commit that referenced this pull request May 9, 2019
@bors
Auto merge of #60672 - Centril:rollup-fhcx463, r=Centril
a784a80 
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
@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019

You're missing some changes in the sgx platform, see https://gist.github.com/fortanix-bot/a355e5bad7852c6b19e58ddff11418f8

@JohnTitor
Copy link
Member Author

@jethrogb Thank you for pointing out, what I should do is to add #![feature(fixed_size_array)] to the top in src/libstd/sys/sgx/rwlock.rs?

@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019

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?

@JohnTitor
Copy link
Member Author

Oh, I missed it, src/libstd/sys/sgx/mod.rs instead? And this PR stabilizes core::array, not fixed_size_array so we should add feature attribute I think.

@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019 •
edited
Loading

Oh, I missed it, src/libstd/sys/sgx/mod.rs instead?

No, src/libstd/lib.rs.

@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019

I think you might get a warning about an unused feature now on non-SGX platforms (but I'm not sure).

@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019

I think your PR might be merged at 028e78d because the failure only happens when compiling with cfg(test, target_env = "sgx") and Rust CI is not gated on that build. A new PR would then be needed to fix this.

@jethrogb jethrogb mentioned this pull request May 9, 2019
Merged
@jethrogb
Copy link
Contributor

jethrogb commented May 9, 2019

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

@JohnTitor
Copy link
Member Author

Oops, sorry... I'll close this.

@JohnTitor JohnTitor closed this May 9, 2019
bors added a commit that referenced this pull request May 10, 2019
@bors
Auto merge of #60684 - jethrogb:jb/sgx-test, r=joshtriplett
0ac53da 
Fix cfg(test) build on SGX

Introduced in #60657

r? @joshtriplett
@pietroalbini pietroalbini mentioned this pull request May 14, 2019
Merged
bors added a commit that referenced this pull request May 14, 2019
@bors
Auto merge of #60838 - pietroalbini:beta-rollup, r=pietroalbini
2bafaaf 
[beta] Rollup backports

Rolled up:

* #60806: [beta] save-analysis: Fix ICE when processing associated constant

Cherry-picked:

* #60837: Update release notes for 1.35.0
* #60657: Stabilize and re-export core::array in std

r? @ghost
@JohnTitor JohnTitor deleted the stabilize-array branch March 27, 2020 00:53
@lukas-code lukas-code mentioned this pull request Nov 2, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 2, 2024
@matthiaskrgr
Rollup merge of rust-lang#132482 - lukas-code:stab-attrs, r=Noratrieb
90c5f86 
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.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 2, 2024
@rust-timer
Unrolled build for rust-lang#132482
bde2adf 
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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Reviewers

@Centril Centril Centril left review comments

Assignees

@cramertj cramertj

Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.36
Development

Successfully merging this pull request may close these issues.

Stabilize the core::array module and reexport in std (for TryFromSliceError)
7 participants
@JohnTitor @rust-highfive @SimonSapin @bors @jethrogb @Centril @cramertj