-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rewrite ...
to ..=
as an idiom lint for Rust 2018 edition
#51043
Comments
Do we have an existing lint for this? |
If we hope to someday get rid of |
One remaining issue of fn main() {
match &5 {
&3...6 => {}
_ => {}
}
} if we just
Note that fn main() {
match &5 {
3..=6 => {} // no &, no (), no whatever
_ => {}
}
} |
I classified it as an idiom lint because the code will not cause a hard error in the new edition, even if it is frowned upon. |
Now that `..=` inclusive ranges are stabilized, people probably shouldn't be using `...` even in patterns, even if it's still legal there (see rust-lang#51043). To avoid drawing attention to `...` being a real thing, let's reword this message to just say "unexpected token" rather "cannot be used in expressions".
three diagnostics upgrades * reword `...` expression syntax error to not imply that you should use it in patterns either (#51043) and make it a structured suggestion * shorten the top-line message for the trivial-casts lint by tucking the advisory sentence into a help note * structured suggestion for pattern-named-the-same-as-variant warning r? @oli-obk
These were stabilized in March 2018's rust-lang#47813, and are the Preferred Way to Do It going forward (q.v. rust-lang#51043).
Our implementation ends up changing the `PatKind::Range` variant in the AST to take a `Spanned<RangeEnd>` instead of just a `RangeEnd`, because the alternative would be to try to infer the span of the range operator from the spans of the start and end subexpressions, which is both hideous and nontrivial to get right (whereas getting the change to the AST right was a simple game of type tennis). This is concerning rust-lang#51043.
lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase We probably need an RFC to actually deprecate the `...` syntax, but here's a candidate implementation for the lint considered in #51043. (My local build is super flaky, but hopefully I got all of the test revisions.)
@zackmdavis if you've got a moment, can you write up a listing of what's left after #51149 landed? |
@alexcrichton: the comment above by @kennytm should still be addressed; the lint suggestion is marked as maybe-incorrect for this reason. If pattern-parentheses are stabilized (which itself reportedly needs more testing), using them for a correct suggestion when needed will be very easy. |
Ok great, thanks! |
visited for T-compiler triage. It seems like it was blocked on stabilization of the pattern-parentheses feature. So what are the next steps, and who wants to own this? |
more triage notes: P-high. @varkor has agreed to take this on and/or mentor it. |
Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint Fixes rust-lang#51043.
Removing from the milestone, as idiom lints are not part of the Rust 2018 release. |
Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint Fixes rust-lang#51043.
Current status
Implemented in #51149 but currently not marked as automatically applicable due to this issue which is explained below
The text was updated successfully, but these errors were encountered: