Skip to content
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

New lint: unnested_or_patterns #5378

Merged
merged 5 commits into from
Jun 8, 2020
Merged

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Mar 28, 2020

changelog: Adds a lint unnested_or_patterns, suggesting Some(0 | 2) as opposed to Some(0) | Some(2). The lint only fires on compilers capable of using #![feature(or_patterns)].

  • The lint is primarily encoded as a pure algorithm which to unnest or-patterns in an ast::Pat (fn unnest_or_patterns) through a MutVisitor. After that is done, and assuming that any change was detected, then pprust::pat_to_string is used to simply convert the transformed pattern into a suggestion.

  • The PR introduces a module utils::ast_utils with a bunch of functions for spanless & nodeless equality comparisons of ASTs.

cc rust-lang/rust#54883

@Centril Centril force-pushed the unnested-or-pats branch 3 times, most recently from 46aa951 to edc2802 Compare March 29, 2020 04:08
@Centril
Copy link
Contributor Author

Centril commented Mar 29, 2020

CI seems happy. 🎉

@bors
Copy link
Collaborator

bors commented Mar 30, 2020

☔ The latest upstream changes (presumably #5380) made this pull request unmergeable. Please resolve the merge conflicts.

@flip1995 flip1995 added A-lint Area: New lints S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Mar 30, 2020
Copy link
Contributor Author

@Centril Centril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(note to self: some mistakes I made to fix before merging)

clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnested_or_patterns.rs Outdated Show resolved Hide resolved
@flip1995 flip1995 self-requested a review March 30, 2020 19:10
@bors
Copy link
Collaborator

bors commented Mar 30, 2020

☔ The latest upstream changes (presumably #5294) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for taking so long for the review. I don't have an excuse, just wasn't really motivated to review PRs recently.

This looks really good. It'll need a rebase + cargo dev update_lints and you may want to address your own comments 😉

@flip1995 flip1995 self-assigned this May 25, 2020
@flip1995
Copy link
Member

flip1995 commented Jun 7, 2020

r? @phansch

No need to review the lint itself, I already did that. A second pair of eyes on fixing the dogfood fallout would be great though!

(I finished this lint, since Centril currently takes a break from OSS and this is too good to let it go to waste)

@rust-highfive rust-highfive assigned phansch and unassigned flip1995 Jun 7, 2020
Copy link
Member

@phansch phansch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I just have to get used to or_patterns more - in some cases I find them harder to parse in my head than the un-nested version. Did you have the same feeling @flip1995? (in any case, r=me for the dogfood changes)

help: nest the patterns
|
LL | if let box (0 | 1 | 2 | 3 | 4) = Box::new(0) {}
| ^^^^^^^^^^^^^^^^^^^^^^^
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoa these suggestions are nice 🤯

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they are built by modifying the AST and then pretty printing it IIUC. Centril definitely knows what he's doing 😄

["as_ptr", "unwrap"] | ["as_ptr", "expect"] => {
lint_cstring_as_ptr(cx, expr, &arg_lists[1][0], &arg_lists[0][0])
},
["as_ptr", "unwrap" | "expect"] => lint_cstring_as_ptr(cx, expr, &arg_lists[1][0], &arg_lists[0][0]),
Copy link
Member

@phansch phansch Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example here, is that really less complex than before? In my mind I first have to think about the precedence to figure out what's going on. Maybe it just takes some time to get used to it.

Copy link
Member

@flip1995 flip1995 Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it just takes some time to get used to it.

I think that's it. But especially this example is really nice IMO. I think it expresses more the thought of ""as_ptr" is the first part, followed by "unwrap" OR "expect"", instead of "it's either an "as_ptr", "unwrap" array OR an "as_ptr", "expect" array. I can see why one would prefer the later way of writing this though.

What I struggeled with on first reviewing this was a pattern like:

(A | B, C | D) => { ... }

Because this is combinatorially evaluated (A+C, A+D, B+C, B+D), which may not be directly obvious, if your not used to this kind of pattern.

@flip1995
Copy link
Member

flip1995 commented Jun 8, 2020

@bors r=flip1995,phansch

@bors
Copy link
Collaborator

bors commented Jun 8, 2020

📌 Commit a9ca832 has been approved by flip1995,phansch

@bors
Copy link
Collaborator

bors commented Jun 8, 2020

⌛ Testing commit a9ca832 with merge 08b84b3...

@bors
Copy link
Collaborator

bors commented Jun 8, 2020

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995,phansch
Pushing 08b84b3 to master...

@bors bors merged commit 08b84b3 into rust-lang:master Jun 8, 2020
@bors bors mentioned this pull request Jun 8, 2020
@matthiaskrgr
Copy link
Member

When rustfixing this lint on nightly, we will always get errors if #![feature(or_patterns)] is not enabled.

The following errors were reported:
error[E0658]: or-patterns syntax is experimental
   --> alacritty_terminal/src/ansi.rs:982:14
    |
982 |             ('B' | 'e', None) => {
    |              ^^^^^^^^^
    |
    = note: see issue #54883 <https://github.com/rust-lang/rust/issues/54883> for more information
    = help: add `#![feature(or_patterns)]` to the crate attributes to enable

should we move this to pedantic/nursery until or_patterns are stable?

@flip1995
Copy link
Member

flip1995 commented Jun 8, 2020

It shouldn't lint, if the or_patterns feature isn't enabled? 😮

@matthiaskrgr
Copy link
Member

Hm, I can't reproduce this with the clippy of latest nightly. clippy 0.0.212 (fd4b177 2020-06-08)

But when I use the master toolchain and use master-clippy (I build clippy using rustc master and put the bins in ~/.rustup/toolchains/master/bin and run cargo +master clippy, I get unnested_or_patterns warnings. Hmm.

}

fn lint_unnested_or_patterns(cx: &EarlyContext<'_>, pat: &Pat) {
if !cx.sess.opts.unstable_features.is_nightly_build() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, we should check, if the feature is enabled here. In that case, this was an oversight on my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants