Stabilise feature(never_type). Introduce feature(exhaustive_patterns) #47630
Conversation
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
|
☔ The latest upstream changes (presumably #47622) made this pull request unmergeable. Please resolve the merge conflicts. |
src/libcore/cmp.rs
Outdated
| @@ -880,24 +880,24 @@ mod impls { | |||
|
|
|||
| ord_impl! { char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 } | |||
|
|
|||
| #[unstable(feature = "never_type", issue = "35121")] | |||
| #[stable(feature = "never_type", since = "1.24.0")] | |||
There was a problem hiding this comment.
Shouldn't this be since = "1.25.0"?
There was a problem hiding this comment.
True, it's too late to make 1.24. Thanks for the catch!
canndrew
force-pushed
the
exhaustive-patterns
branch
from
cc3e60c
to
72ce701
Compare
kennytm
added
the
S-waiting-on-review
There was a problem hiding this comment.
I believe when we split a feature gate into stable part and unstable part, we typically try to rename the stable part rather than the unstable part. So in this case ! would be stabilized under something like feature(never_bang) and what you have as feature(exhaustive_patterns) would continue to be feature(never_type). This minimizes churn for libraries that currently use never_type. Their existing code would continue to compile.
|
If I understand correctly, this will also resolve the future compatibiltiy question (and make the change to fallback to @bors try |
Stabilise feature(never_type). Introduce feature(exhaustive_patterns) This stabilizes `!`, removing the feature gate as well as the old defaulting-to-`()` behavior. The pattern exhaustiveness checks which were covered by `feature(never_type)` have been moved behind a new `feature(exhaustive_patterns)` gate.
kennytm
added
S-waiting-on-crater
|
☀️ Test successful - status-travis |
I haven’t followed all the discussions around |
|
Never mind, I saw your explenation on #35121 (comment). As to empty enums, this also causes enum Void {}
let r: Result<u32, Void> = Ok(4);
let Ok(i) = r; |
|
@dtolnay That would mean only the pattern-matching stuff is behind the As it is I deleted the |
|
@canndrew huh, I've never seen those particular errors before |
|
Crater run started. |
|
Crater run is currently stalled due to runs taking up more disk space than they used to. We've started up a bigger box and are working through the backlog - ETA another week or so, sorry :( |
Specifically, I added |
canndrew
force-pushed
the
exhaustive-patterns
branch
from
72ce701
to
71fa69c
Compare
|
When this is ready for another run can you get bors to do a try? Then we'll prioritise this PR since it's been idle and waiting for a while. |
nikomatsakis
force-pushed
the
exhaustive-patterns
branch
from
71fa69c
to
c3beef6
Compare
|
📌 Commit a8a0c69 has been approved by |
bors
added
S-waiting-on-bors
Stabilise feature(never_type). Introduce feature(exhaustive_patterns) This stabilizes `!`, removing the feature gate as well as the old defaulting-to-`()` behavior. The pattern exhaustiveness checks which were covered by `feature(never_type)` have been moved behind a new `feature(exhaustive_patterns)` gate.
kennytm
added
the
relnotes
|
☀️ Test successful - status-appveyor, status-travis |
|
@clarcharr I've submitted a PR for replacing |
…kennytm re-mark the never docs as unstable Fixes rust-lang#54198 This stability attribute was removed in rust-lang#47630, but not replaced with a `#[stable]` attribute, and when rust-lang#50121 reverted that stabilization, it didn't set the docs back to unstable. I'm concerned as to why it was allowed to not have the stability attribute at all, but at least this can put it back. I'm nominating this for beta backport because it's a really small change, and right now our docs are in an awkward position where the `!` type is technically unstable to use, but the docs don't say so the same way any other library feature would. (And this is also the case *on stable* now, but i'm not suggesting a stable backport for a docs fix.)
This stabilizes
!, removing the feature gate as well as the old defaulting-to-()behavior. The pattern exhaustiveness checks which were covered byfeature(never_type)have been moved behind a newfeature(exhaustive_patterns)gate.