remove deduplicate-diagnostics=no in suspicious_operation_groupings.stderr#13266
remove deduplicate-diagnostics=no in suspicious_operation_groupings.stderr#13266kyoto7250 wants to merge 1 commit into
deduplicate-diagnostics=no in suspicious_operation_groupings.stderr#13266Conversation
rustbot
added
the
S-waiting-on-review
| | ^^^^^^^^^^^ help: did you mean: `s1.b * s2.b` | ||
|
|
||
| error: this sequence of operators looks suspiciously like a bug | ||
| --> tests/ui/suspicious_operation_groupings.rs:88:19 |
There was a problem hiding this comment.
This error is identical to the one at line 23, so it can be safely removed.
| | ^^^^^^^^^^^ help: did you mean: `s1.c * s2.c` | ||
|
|
||
| error: this sequence of operators looks suspiciously like a bug | ||
| --> tests/ui/suspicious_operation_groupings.rs:136:42 |
There was a problem hiding this comment.
This error is identical to the one at line 77 91, so it can be safely removed.
edit: I made a mistake with the line numbers in the comment
There was a problem hiding this comment.
this would indicate there's a place that should be using span_lint_hir_and_then but is not
There was a problem hiding this comment.
In this lint, span_lint_and_sugg is used, but what is the difference between it and span_lint_hir_and_then?
It seems to me that specifying hir may not be necessary in this case.
There was a problem hiding this comment.
It tells the compiler at what node the lint is being emitted for the purposes of #[allow]/etc, if not specified it will be the node that check_xxx was called on
There was a problem hiding this comment.
Please let me confirm my understanding. I think this duplicate error output is coming from both sides of binOp.
I still don't understand the relationship between solving this problem and the need to use span_lint_hir_and_then.
Centri3
left a comment
Centri3
left a comment
There was a problem hiding this comment.
Maybe this wouldn't work, but usually this is done by early returning if the other check successfully lints?
On span_lint_hir_and_then, this will need to use it one day as it doesn't lint on the exact node in check_expr, however that'd require rewriting the whole lint. I'm curious how that'd fix it? It does hash the diagnostic it's about to emit in emit_diagnostic so maybe the node differing causes it to emit regardless of deduplicate-diagnostics, but I'd like confirmation on that
|
r? rust-lang/clippy |
|
Yeah, I don't think this is the right fix. We should use the right spans whilst linting. Why is this lint emitting duplicate diagnostics? |
|
☔ The latest upstream changes (presumably #13440) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (possibly d28d234) made this pull request unmergeable. Please resolve the merge conflicts. |
rustbot
added
S-waiting-on-author
|
Closing because no activity and not the right fix. |
7 participants
a part of #12379.
In this PR, we will update the lint to store already outputted Spans internally to prevent suspicious_operation_groupings from outputting the same error multiple times.
changelog:
Fixed duplicate errors in suspicious_operation_groupings.