Skip to content

/rust

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

Closed
nikomatsakis opened this Issue May 24, 2018 · 10 comments

Comments

Assignees

@varkor varkor

Labels
A-edition-2018-lints A-rust-2018-preview C-enhancement P-high T-compiler WG-epoch
Projects
None yet
Milestone
No milestone
9 participants
@nikomatsakis @zackmdavis @kennytm @alexcrichton @pnkfelix @nrc @varkor @XAMPPRocky @Mark-Simulacrum
@nikomatsakis
Copy link
Contributor

nikomatsakis commented May 24, 2018 •
edited by alexcrichton

Current status

Implemented in #51149 but currently not marked as automatically applicable due to this issue which is explained below

@nikomatsakis nikomatsakis added the A-rust-2018-preview label May 24, 2018

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented May 24, 2018

Do we have an existing lint for this?

@nikomatsakis nikomatsakis added the WG-epoch label May 24, 2018

@zackmdavis

This comment has been minimized.

Sign in to view
Copy link
Member

zackmdavis commented May 25, 2018

If we hope to someday get rid of ... in patterns (the current description of #28237 describes it as "(silently) deprecated"), wouldn't we want a future-incompatible lint rather than an idiom lint? (... in expressions is already illegal.)
@kennytm

This comment has been minimized.

Sign in to view
Copy link
Member

kennytm commented May 26, 2018

One remaining issue of a..=b pattern is #48501. When stabilizing a..=b, to avoid the confusing interpretation of &a...b, in the following example:

fn main() {
    match &5 {
        &3...6 => {}
        _ => {}
    }
}

if we just s/.../..=/g the code will error with

error: the range pattern here has ambiguous interpretation
 --> src/main.rs:3:10
  |
3 |         &3..=6 => {}
  |          ^^^^^ help: add parentheses to clarify the precedence: `(3 ..=6)`

Note that pattern_parentheses (#48500) is still unstable 🙃. However, given that default binding modes (#42640) is already stable, an even more idiomatic fix would probably be

fn main() {
    match &5 {
        3..=6 => {}   // no &, no (), no whatever
        _ => {}
    }
}

zackmdavis added a commit to zackmdavis/rust that referenced this issue May 29, 2018

@zackmdavis
inclusive range syntax future-incompatibility lint (`...` → `..=`) 
This is concerning rust-lang#51043.
894ded0

zackmdavis added a commit to zackmdavis/rust that referenced this issue May 29, 2018

@zackmdavis
inclusive range syntax future-incompatibility lint (`...` → `..=`) 
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). That this might break
Clippy and RLS nightlies in the process is regretted, but accepted.

This is concerning rust-lang#51043.
1ecf4e4

@zackmdavis zackmdavis referenced this issue May 29, 2018

Merged

lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase #51149

@nikomatsakis nikomatsakis referenced this issue May 29, 2018

Closed

Tracking issue for RFC 554: `pattern_parentheses` feature #51087

5 of 5 tasks complete
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented May 30, 2018

@zackmdavis

If we hope to someday get rid of ... in patterns (the current description of #28237 describes it as "(silently) deprecated"), wouldn't we want a future-incompatible lint rather than an idiom lint? (... in expressions is already illegal.)

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.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 3, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
21be599

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 3, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
43fd6cd

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 3, 2018

@zackmdavis
migrate codebase to `..=` inclusive range patterns 
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).
3a5e8bb

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 3, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
a59fa97

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 19, 2018

@zackmdavis
migrate codebase to `..=` inclusive range patterns 
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).
02f2587

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 19, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
6418c7f

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 21, 2018

@zackmdavis
migrate codebase to `..=` inclusive range patterns 
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).
44fc201

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 21, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
ac5ae84

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 24, 2018

@zackmdavis
structured suggestion and rewording for `...` expression syntax error 
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".
0bd5ac8

@zackmdavis zackmdavis referenced this issue Jun 24, 2018

Merged

three diagnostics upgrades #51750

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 24, 2018

@zackmdavis
structured suggestion and rewording for `...` expression syntax error 
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".
fb9a341

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 24, 2018

@zackmdavis
structured suggestion and rewording for `...` expression syntax error 
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".
a417518

bors added a commit that referenced this issue Jun 25, 2018

@bors
Auto merge of #51750 - zackmdavis:superstructure, r=oli-obk 
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
Loading status checks…
8acec1f

bors added a commit that referenced this issue Jun 26, 2018

@bors
Auto merge of #51149 - zackmdavis:․․․_to_․․=, r=nikomatsakis 
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.)
Loading status checks…
3aeb307

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 26, 2018

@zackmdavis
migrate codebase to `..=` inclusive range patterns 
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).
0577155

zackmdavis added a commit to zackmdavis/rust that referenced this issue Jun 26, 2018

@zackmdavis
inclusive range syntax lint (`...` → `..=`) 
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.
3fb76f4

bors added a commit that referenced this issue Jun 26, 2018

@bors
Auto merge of #51149 - zackmdavis:․․․_to_․․=, r=nikomatsakis 
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.)
Loading status checks…
0cf0691

@nrc nrc added the A-edition-2018-lints label Jul 2, 2018

@nrc nrc referenced this issue Jul 4, 2018

Closed

2018 edition lints #52047

11 of 15 tasks complete
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jul 11, 2018

@zackmdavis if you've got a moment, can you write up a listing of what's left after #51149 landed?

@alexcrichton alexcrichton added this to the Rust 2018 Release Candidate milestone Jul 11, 2018

@zackmdavis

This comment has been minimized.

Sign in to view
Copy link
Member

zackmdavis commented Jul 12, 2018 •
edited

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.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jul 12, 2018

Ok great, thanks!

@Mark-Simulacrum Mark-Simulacrum modified the milestones: Rust 2018 Release Candidate, Rust 2018 Release Jul 24, 2018

@zackmdavis zackmdavis referenced this issue Jul 25, 2018

Closed

Should the rust_2018_idioms lint group be mentioned in documentation? #52679

@XAMPPRocky XAMPPRocky added C-enhancement T-compiler labels Oct 2, 2018

@zackmdavis zackmdavis referenced this issue Oct 31, 2018

Merged

initial draft of 'testing rust 2018' #286

@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Nov 8, 2018

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?

@varkor varkor self-assigned this Nov 8, 2018

@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Nov 8, 2018

more triage notes: P-high. @varkor has agreed to take this on and/or mentor it.

@pnkfelix pnkfelix added the P-high label Nov 8, 2018

@varkor varkor referenced this issue Nov 10, 2018

Merged

Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint #55852

pietroalbini added a commit to pietroalbini/rust that referenced this issue Nov 12, 2018

@pietroalbini
Rollup merge of rust-lang#55852 - varkor:dotdotequals-lint, r=zackmdavis 
Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint

Fixes rust-lang#51043.
Verified
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
70d6c53
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented Nov 13, 2018

Removing from the milestone, as idiom lints are not part of the Rust 2018 release.

@nikomatsakis nikomatsakis removed this from the Rust 2018 Release milestone Nov 13, 2018

pietroalbini added a commit to pietroalbini/rust that referenced this issue Nov 15, 2018

@pietroalbini
Rollup merge of rust-lang#55852 - varkor:dotdotequals-lint, r=zackmdavis 
Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint

Fixes rust-lang#51043.
Verified
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
3c7acc7

@bors bors closed this in #55852 Nov 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.