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
alexcrichton
force-pushed
the
features-clean
branch
from
509a883
to
4fcde6e
Compare
|
@bors: r=aturon On Wed, Jun 17, 2015 at 1:04 PM, bors notifications@github.com wrote:
|
|
📌 Commit 4fcde6e has been approved by |
|
⌛ 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
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.