Break apart global unstable features #26192
Conversation
|
r? @aturon |
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
|
Woah! This will help a lot! 👍 |
alexcrichton
force-pushed
the
features-clean
branch
from
21ad735
to
d7791b5
Compare
|
☔ The latest upstream changes (presumably #25777) made this pull request unmergeable. Please resolve the merge conflicts. |
|
OK, initial pass done -- this is fantastic. I marked a few places where I think we can probably just stabilize for 1.2 or deprecate. But it's fine to punt that to a separate pass if you prefer. Otherwise r=me. |
|
So my initial strategy was going to be to land this and then follow up with a blanket deprecation pass, following that up with a blanket stabilization pass. The idea would be to only deprecate things that should have been deprecated some time ago, and also only stabilize minor apis that should have been stable awhile ago. I'm rethinking this, though, as if I'm using these unstable features I may have to update code twice where otherwise I could just lump all the changes into this one PR. Thoughts on whether these blanket passes for "easy" things should happen now or later? I do suspect it will delay this PR to add more stabilizations to it, but we still have a few weeks to the release (and I wouldn't want to cherry-pick stabilizations into the 1.1 branch). |
|
Yeah, to avoid unnecessary churn on Nightly, it seems prudent to at least pick off the easy stuff we can get quick consensus on. |
|
Folding them into this seems fine - preferably the deprecation and stabilization passes would each happen in their own commit for ease of review. |
alexcrichton
force-pushed
the
features-clean
branch
3 times, most recently
from
60906ee
to
64bfa63
Compare
|
OK, I have pushed a proposed set of stabilizations and deprecations, each of which is separate as one feature per commit. I can squash everything later, but wanted to make sure it was clear what's going on where. I'm also now going through the process of updating all the tests and warnings that come out of these changes (a commit to be added). |
|
Is the plan to delete the deprecated stuff in 1.3? |
|
☔ The latest upstream changes (presumably #26154) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I'm positive-to-neutral on all these changes. |
|
@sfackler yeah I'd want to clean out deprecated unstable items after the next release (e.g. when master is 1.3). |
|
I'll also mention that I'm avoiding rebasing for now to ensure commit comments are not lost, but I'll rebase once it's all good to go. |
alexcrichton
force-pushed
the
features-clean
branch
from
64bfa63
to
e1d0efc
Compare
|
Ok I've pushed a follow-up to address some comments and also stabilize This PR now passes all test as well! |
|
One point of note to highlight is sfackler's comment about whether |
|
Is anyone asking for a stable |
|
Yeah, I wouldn't mind holding off on the BorrowState stuff for now. Otherwise I'm happy with this. |
alexcrichton
force-pushed
the
features-clean
branch
from
9246f56
to
2d3ffb2
Compare
|
Sounds good to me! I've rebased and removed the stabilization of |
|
☔ The latest upstream changes (presumably #25844) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
force-pushed
the
features-clean
branch
from
b93bbc8
to
2f3d6c8
Compare
|
⌛ Testing commit 4fcde6e with merge 538eb1d... |
|
💔 Test failed - auto-win-gnu-64-opt |
|
@bors: retry On Wed, Jun 17, 2015 at 3:50 PM, bors notifications@github.com wrote:
|
This commit shards the all-encompassing `core`, `std_misc`, `collections`, and `alloc` features into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized. A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.
|
💔 Test failed - auto-win-gnu-64-opt |
alexcrichton
force-pushed
the
features-clean
branch
from
4fcde6e
to
ec33338
Compare
|
@bors: r=aturon On Wed, Jun 17, 2015 at 8:16 PM, bors notifications@github.com wrote:
|
|
📌 Commit ec33338 has been approved by |
This commit shards the all-encompassing `core`, `std_misc`, `collections`, and `alloc` features into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized. A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.
ghost
mentioned this pull request
…richton This seems to have slipped through the cracks in #26192. r? @alexcrichton
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.
This commit shards the all-encompassing
core,std_misc,collections, andallocfeatures into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized.A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.