-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Closes #54538: unused_patterns
lint
#54820
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
Closes #54538: unused_patterns
lint
#54820
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @zackmdavis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
24eddc4
to
f976927
Compare
unused_patterns
lintunused_patterns
lint
unused_patterns
lintunused_patterns
lint
@nikomatsakis This is ready for review. The @zackmdavis Thank you for input on this as well. For the issue #54538 I've been going through Niko on communication since I originally reached out to them about it. If you do have additional input on this I would appreciate it as well! (I missed the original |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
f976927
to
93eb6f6
Compare
@@ -12,6 +12,6 @@ | |||
|
|||
fn main() { | |||
match 0 { | |||
(pat) => assert_eq!(pat, 0) | |||
pat => assert_eq!(pat, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test may not be serving a purpose anymore with the removal of parentheses. If it should stick around, I can keep or this change or silence the warning
that now gets generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to somehow not lint on cases where parens in patterns are necessary, and test such cases. I don't offhand know the spec for when parens-in-patterns are truly necessary, but I don't think this patch is there yet. Consider this program:
fn main() {
match &2 {
&1..=3 => {},
_ => {}
}
}
We get an error (added in 6399d16) imploring us to add parentheses:
error: the range pattern here has ambiguous interpretation
--> paren.rs:3:10
|
3 | &1..=3 => {},
| ^^^^^ help: add parentheses to clarify the precedence: `(1 ..=3)`
error: aborting due to previous error
But if we do so, then a compiler built on this branch fires the lint and says that we shouldn't have:
zmd@ReflectiveCoherence:~/Code/Misc$ rustc +stage1 paren.rs
warning: unnecessary parentheses around pattern
--> paren.rs:3:10
|
3 | &(1..=3) => {},
| ^^^^^^^ help: remove these parentheses
|
= note: #[warn(unused_parens)] on by default
(_) => {} //~ WARNING: unnecessary parentheses around pattern | ||
(y) => {} //~ WARNING: unnecessary parentheses around pattern | ||
(ref r) => {} //~ WARNING: unnecessary parentheses around pattern | ||
e @ 1...2 | (e @ (3...4)) => {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
..=
is the modern style.
It still works in the comments— |
Oh, looks like the bot already reassigned it hours ago because the r-question magic phrase appeared in your comment. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
366ab55
to
ae05749
Compare
@zackmdavis There is no warning for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good — but I think we could make it more precise with relative ease. I left a comment. What do you think?
ae05749
to
2a2ed22
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
2a2ed22
to
2cb37ea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I left a review here, but as I mentioned on Zulip, I realized that my strategy for fixing the problem isn't quite going to work, because in the lint visitor, you are not in control of what gets visited.
I am debating the best fix. One option would be to keep a little mutable state in the UnusedParens
lint itself; we could for example add the ids for 'necessary' parens into a set stored in the lint. Then when we reach the paren node, we can check if it is present in that set.
I am not thrilled about that solution (mutable state == more complexity) but I'm not sure I see a better choice just now, given the way lints are setup.
src/librustc_lint/unused.rs
Outdated
|
||
fn check_pat(&mut self, cx: &EarlyContext, p: &ast::Pat) { | ||
use syntax::ast::PatKind::{Paren, Range}; | ||
if let Some(subpattern) = UnusedParens::is_high_precedence_unary_pat(p) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment here would be good. Something like:
The only "necessary" use for parentheses is to when you have a high-precedence pattern (like &P
) that is applied to a low-precedence pattern (like a ..= b
). This is because &a ..= b
would be parsed incorrectly.
Discussing with @Manishearth, it seems like another option would be to modify the lint to override Or we add a mutable set. I'm not sure if I have an opinion about which would be best. |
This uses a copied version of `check_unused_parens_expr` that is specific to `ast::Pat`. `check_unused_parens_` could possibly be made more generic to work with any `ast::*` that has `node` and `span` fields. This also only checks for the case of parens around the wildcard pattern. It covers the case highlighted in the issue, but could check for a lot more.
2cb37ea
to
0e411c2
Compare
After some thorough discussion with @nikomatsakis on the Zulip topic, we decided it would be best to not try and be more precise with the lint as it would introduce more complexity, and expressions are also not this precise. The complexity introduced would be both in the logic of the lint, as well as warnings on patterns that would become less readable with unnecessary parentheses removed. For example, the pattern |
@bors r+ |
📌 Commit 0e411c2 has been approved by |
…erns-lint, r=nikomatsakis Closes rust-lang#54538: `unused_patterns` lint Closes rust-lang#54538 r? @nikomatsakis
Rollup of 11 pull requests Successful merges: - #54820 (Closes #54538: `unused_patterns` lint) - #54963 (Cleanup rustc/session) - #54991 (add test for #23189) - #55025 (Add missing lifetime fragment specifier to error message.) - #55047 (doc: make core::fmt::Error example more simple) - #55048 (Don't collect to vectors where unnecessary) - #55060 (clarify pointer add/sub function safety concerns) - #55062 (Make EvalContext::step public again) - #55066 (Fix incorrect link in println! documentation) - #55081 (Deduplicate tests) - #55088 (Update rustc documentation link) Failed merges: r? @ghost
Closes #54538
r? @nikomatsakis