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

Don't hash lints differently to non-lints. #120490

Merged
merged 1 commit into from
Jan 31, 2024

Conversation

nnethercote
Copy link
Contributor

Diagnostic::keys, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in #88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.

This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:

error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^

and with this change we also get this error:

error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |

I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.

r? @estebank

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jan 30, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jan 30, 2024

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@chenyukang
Copy link
Member

chenyukang commented Jan 30, 2024

ah, my first rustc PR left this surprising behavior 😅 .

I think we may need to investigate why two diagnostics with the same primary message(error: method's name is the same as an existing method in a trait), but have different note.

Give this extra diagnostic will still make users confused, even the note is different, but the second one didn't give more extra information.

@chenyukang
Copy link
Member

oh, I missed it, they are different line of code, ignore me.

@flip1995
Copy link
Member

I think emitting both errors is fine here. I'd say this is rather an issue on the error creation itself. I think it would be better, if the note would list all conflicting implementations and the error would only be emitted once. But that is unrelated to this PR.

@bors
Copy link
Contributor

bors commented Jan 30, 2024

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

Comment on lines 64 to 74
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
| ^^^^^^^^^^^^^^^^
Copy link
Contributor

Choose a reason for hiding this comment

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

You need to modify the .rs file as well, don't you? Can you locally run python ./x.py test src/tools/clippy to confirm this is actually passing now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I ran the clippy tests before creating the PR, it works without changing the .rs file. If I add the second ERROR line it also works. And if I add a third ERROR line then the test fails.

So I have updated with the second ERROR added, because that's what one would expect. I don't know why it was working without the second ERROR.

Copy link
Member

Choose a reason for hiding this comment

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

We don't enforce ERROR annotations yet. Thanks for adding it!

@estebank
Copy link
Contributor

r=me

`Diagnostic::keys`, which is used for hashing and equating diagnostics,
has a surprising behaviour: it ignores children, but only for lints.
This was added in rust-lang#88493 to fix some duplicated diagnostics, but it
doesn't seem necessary any more.

This commit removes the special case and only four tests have changed
output, with additional errors. And those additional errors aren't
exact duplicates, they're just similar. For example, in
src/tools/clippy/tests/ui/same_name_method.rs we currently have this
error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |         ^^^^^^^^^^^^^^^^
```
I think printing this second argument is reasonable, possibly even
preferable to hiding it. And the other cases are similar.
@nnethercote
Copy link
Contributor Author

I rebased and added the second ERROR to the clippy test, even though it wasn't necessary, because it's what people would expect.

@bors r=estebank

@bors
Copy link
Contributor

bors commented Jan 30, 2024

📌 Commit 4225a1e has been approved by estebank

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 30, 2024
Nadrieril added a commit to Nadrieril/rust that referenced this pull request Jan 31, 2024
…estebank

Don't hash lints differently to non-lints.

`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in rust-lang#88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.

This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.

r? `@estebank`
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 31, 2024
Rollup of 12 pull requests

Successful merges:

 - rust-lang#120207 (check `RUST_BOOTSTRAP_CONFIG` in `profile_user_dist` test)
 - rust-lang#120321 (pattern_analysis: cleanup the contexts)
 - rust-lang#120323 (On E0277 be clearer about implicit `Sized` bounds on type params and assoc types)
 - rust-lang#120355 (document `FromIterator for Vec` allocation behaviors)
 - rust-lang#120396 (Account for unbounded type param receiver in suggestions)
 - rust-lang#120430 (std: thread_local::register_dtor fix proposal for FreeBSD.)
 - rust-lang#120435 (Suggest name value cfg when only value is used for check-cfg)
 - rust-lang#120470 (Mark "unused binding" suggestion as maybe incorrect)
 - rust-lang#120472 (Make duplicate lang items fatal)
 - rust-lang#120490 (Don't hash lints differently to non-lints.)
 - rust-lang#120495 (Remove the `abi_amdgpu_kernel` feature)
 - rust-lang#120501 (rustdoc: Correctly handle attribute merge if this is a glob reexport)

Failed merges:

 - rust-lang#120346 (hir: Refactor getters for owner nodes)

r? `@ghost`
`@rustbot` modify labels: rollup
@Nadrieril
Copy link
Member

Got this failure in rollup, which at a glance looks like it's coming from this PR.

@Nadrieril
Copy link
Member

Welp, apparently came from a different PR

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 31, 2024
Rollup of 9 pull requests

Successful merges:

 - rust-lang#120207 (check `RUST_BOOTSTRAP_CONFIG` in `profile_user_dist` test)
 - rust-lang#120321 (pattern_analysis: cleanup the contexts)
 - rust-lang#120355 (document `FromIterator for Vec` allocation behaviors)
 - rust-lang#120430 (std: thread_local::register_dtor fix proposal for FreeBSD.)
 - rust-lang#120469 (Provide more context on derived obligation error primary label)
 - rust-lang#120472 (Make duplicate lang items fatal)
 - rust-lang#120490 (Don't hash lints differently to non-lints.)
 - rust-lang#120495 (Remove the `abi_amdgpu_kernel` feature)
 - rust-lang#120501 (rustdoc: Correctly handle attribute merge if this is a glob reexport)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit be4f8e2 into rust-lang:master Jan 31, 2024
11 checks passed
@rustbot rustbot added this to the 1.77.0 milestone Jan 31, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 31, 2024
Rollup merge of rust-lang#120490 - nnethercote:Diagnostic-hashing, r=estebank

Don't hash lints differently to non-lints.

`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in rust-lang#88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.

This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.

r? `@estebank`
@nnethercote nnethercote deleted the Diagnostic-hashing branch January 31, 2024 22:10
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 8, 2024
…estebank

Don't hash lints differently to non-lints.

`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in rust-lang#88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.

This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.

r? `@estebank`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants