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

match_wildcard improvements #6863

Merged
merged 3 commits into from
Mar 18, 2021
Merged

match_wildcard improvements #6863

merged 3 commits into from
Mar 18, 2021

Conversation

Jarcho
Copy link
Contributor

@Jarcho Jarcho commented Mar 7, 2021

fixes: #6604
fixes: #5733
fixes: #6862

#5733 is only fixed in the normal case, if different paths are used for the variants then the same problem will occur. It's cause by def_path_str returning an utterly useless result. I haven't dug into why yet.

For #6604 there should be some discussion before accepting this. It's easy enough to change the message rather than disable the lint for Option and Result.

changelog: Attempt to find a common path prefix for match_wildcard_for_single_variants and wildcard_enum_match_arm
changelog: Don't lint op Option and Result for match_wildcard_for_single_variants and wildcard_enum_match_arm
changelog: Consider or patterns and Self prefix for match_wildcard_for_single_variants and wildcard_enum_match_arm

@rust-highfive
Copy link

r? @llogiq

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 7, 2021
@Jarcho Jarcho force-pushed the wild_enum_match branch 3 times, most recently from 45c41db to 0523137 Compare March 8, 2021 05:49
@llogiq
Copy link
Contributor

llogiq commented Mar 8, 2021

I'm not completely sure about the wording of the warning. Otherwise this looks good.

@llogiq
Copy link
Contributor

llogiq commented Mar 8, 2021

Also a test with a #[non-exhaustive] enum would probably make sense.

@Jarcho Jarcho force-pushed the wild_enum_match branch from 7b9bc87 to 456a541 Compare March 8, 2021 16:15
@bors
Copy link
Contributor

bors commented Mar 8, 2021

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

@Jarcho
Copy link
Contributor Author

Jarcho commented Mar 8, 2021

I left the wording as is, but it could be improved.

The suggestion to change the message instead of ignore the lint for Option and Result was from @camsteffen. I can definitely agree with it for wildcard_enum_match_arm, which is just banning wild matches outright. I'm not really sure about match_wildcard_for_single_variants though. The reason for the lint is the wild match is standing in for a singled variant, but new ones might be added in the future. This is just not true for most std types.

@llogiq llogiq changed the title match_wildcard imporvements match_wildcard improvements Mar 9, 2021
@llogiq
Copy link
Contributor

llogiq commented Mar 9, 2021

Does the standard library really have that many single-variant enums?

@Jarcho
Copy link
Contributor Author

Jarcho commented Mar 9, 2021

It's for when the wildcard matches only a single variant, not when the enum has only one.

@camsteffen
Copy link
Contributor

Fyi my suggestion for #6604 was intended for all enums. Personally I think that if a _ can be changed to Variant(..) then it should be. It makes the code more clear at little cost.

@Jarcho
Copy link
Contributor Author

Jarcho commented Mar 9, 2021

I can think of two reasons to use the lint.

  • Not having code silently break when a variant is added for an enum. Especially when wild match was just a lazy way to write out the last variant. In this case most std types should be ignored, they will never change.
  • Clarity reasons. In which case you would want it to lint on std types.

I would use the lint for the former, I don't really care about the latter. That's just how I would personally use it.

@camsteffen
Copy link
Contributor

I see what you mean. The first reason is generally more important and could be the only important reason for others as well.

Perhaps we need a new pedantic lint wild_single_variant_std to be added some other time.

let mut suggestions: Vec<_> = variants.iter().cloned().map(format_suggestion).collect();
let message = if adt_def.is_variant_list_non_exhaustive() {
suggestions.push("_".into());
"match on non-exhaustive enum doesn't explicitly match all known variants"
Copy link
Contributor

Choose a reason for hiding this comment

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

I still don't like that this message references a "non-exhaustive enum" where the lint doesn't even trigger on enums that have been marked #[non-exhaustive]. How about "match on the single remaining variant by wildcard" instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like I used the wrong message there.

@Jarcho Jarcho force-pushed the wild_enum_match branch 2 times, most recently from 3b25ecf to 76fbe92 Compare March 16, 2021 17:28
@llogiq
Copy link
Contributor

llogiq commented Mar 17, 2021

I'm still not completely sure about the message: "will miss any" reads like variants added in the future would not be matched when the opposite is the case. How about "will also match any" instead?

@bors
Copy link
Contributor

bors commented Mar 17, 2021

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

Jarcho added 2 commits March 17, 2021 12:04
…um_match_arm` lints

Don't lint on `Result` and `Option` types.
Considers `or` patterns.
Considers variants prefixed with `Self`
Suggestions will try to find a common prefix rather than just using the full path
@Jarcho
Copy link
Contributor Author

Jarcho commented Mar 17, 2021

Changed. Should the match on non-exhaustive enums be separated into it's own lint? The whole purpose of them is to not necessarily match every variant.

@llogiq
Copy link
Contributor

llogiq commented Mar 18, 2021

Good question. But not a blocker, so in the interest of avoiding more rebasing work for you, we can address this in a followup. @bors r+

@bors
Copy link
Contributor

bors commented Mar 18, 2021

📌 Commit d5a7941 has been approved by llogiq

@bors
Copy link
Contributor

bors commented Mar 18, 2021

⌛ Testing commit d5a7941 with merge 4d68619...

@bors
Copy link
Contributor

bors commented Mar 18, 2021

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: llogiq
Pushing 4d68619 to master...

@bors bors merged commit 4d68619 into rust-lang:master Mar 18, 2021
@Jarcho Jarcho deleted the wild_enum_match branch April 6, 2021 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
5 participants