Skip to content

error-msg: impl better suggestion for E0532 #108971

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Mar 16, 2023

Conversation

Ezrashaw
Copy link
Contributor

Fixes #106862

No test as there is already a test which is nearly identical to the example in the linked issue.

@rustbot
Copy link
Collaborator

rustbot commented Mar 10, 2023

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

@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. labels Mar 10, 2023
@WaffleLapkin
Copy link
Member

Also I would like to see a test where

  • Some names are the same (e.g. Foo(x, a)/struct Foo { x: (), y: () })
  • There are patterns that are not simply bindings (e.g. Foo(Some(x)), struct Foo { field: Option<()> })
  • The pattern is for an enum (e.g. Enum::Var(x), enum Enum { Var { a: () } })

@Ezrashaw Ezrashaw force-pushed the E0532-better-binding-names branch from 93b18fb to bf3659b Compare March 10, 2023 21:03
@Ezrashaw
Copy link
Contributor Author

@WaffleLapkin I've added a test with all your cases. One of the suggestions was poor (Foo { x: x }), it's been updated.

@WaffleLapkin
Copy link
Member

Hm, I thought about another test case: what about the case, when the pattern and the struct have different number of fields? i.e. struct S { x: u32, y: u32 }/S(a); struct S { field: u32 }/S(x, y); struct S {}/S(a); and struct S { field: u32 }/S().

If the struct has more fields than the pattern, we could either suggest .. or excess_field0: _, excess_field1: _ (not sure what's better).

Also, is this code run on expressions too? If so, we should test it too (although it seems like expressions go in PathSource::Expr?... it's unclear from the docs and hard to guess while reviewing on gh)

@Ezrashaw
Copy link
Contributor Author

Ezrashaw commented Mar 14, 2023

@WaffleLapkin The current behaviour for:

  • when the tuple has more fields (eg struct S { field: u32 }/S(x, y) is just to drop the excess fields (eg help: use struct pattern syntax instead: `S { field: x }`), which I think is ok.
  • when the tuple is missing fields (eg struct S { x: u32, y: u32 }/S(a)) is to ignore extra struct fields, obviously this is bad. I'd suggest just putting them in as S { field1: x, field2, field3 }. People might want to use those fields and IMHO we shouldn't preemptively ignore them; worst case is a unused warning.

Also, is this code run on expressions too?

No? Maybe in some cases? It is quite confusing, although in the expression position the following code:

fn main() {
    struct S { x: u32, y: u32 }
    
    let a = 5;
    let b = 5;
    let x = S(a, b);
}

creates the nonsensical suggestion:

error[E0423]: expected function, tuple struct or tuple variant, found struct `S`
 --> <anon>:6:13
  |
2 |     struct S { x: u32, y: u32 }
  |     --------------------------- `S` defined here
...
6 |     let x = S(a, b);
  |             ^^^^^^^
  |
help: use struct literal syntax instead
  |
6 |     let x = S { x: val, y: val };
  |             ~~~~~~~~~~~~~~~~~~~~
help: a local variable with a similar name exists
  |
6 |     let x = a(a, b);
  |             ~

(note that this suggestion is separate from what this PR touches)

@bors
Copy link
Collaborator

bors commented Mar 14, 2023

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

@Ezrashaw Ezrashaw force-pushed the E0532-better-binding-names branch from bf3659b to 5360b92 Compare March 14, 2023 08:04
@Ezrashaw
Copy link
Contributor Author

Implemented "when the tuple is missing fields". Also rebased and updated tests.

I think that removing the span_to_snippet will be difficult because you have to compare the old and new field; you can't just suggest around the fields.

@WaffleLapkin
Copy link
Member

I think that removing the span_to_snippet will be difficult because you have to compare the old and new field; you can't just suggest around the fields.

Alright, I see. I won't block this PR on removing span_to_snippet then.

@WaffleLapkin WaffleLapkin added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 14, 2023
@Ezrashaw Ezrashaw force-pushed the E0532-better-binding-names branch from 5360b92 to 8a55ad7 Compare March 14, 2023 09:55
@Ezrashaw
Copy link
Contributor Author

@WaffleLapkin Whoops, thought I had already done that but however.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 14, 2023
@Ezrashaw Ezrashaw force-pushed the E0532-better-binding-names branch from 8a55ad7 to bd17322 Compare March 15, 2023 09:20
@Ezrashaw
Copy link
Contributor Author

@WaffleLapkin Done. Thanks for all the feedback.

@WaffleLapkin
Copy link
Member

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Mar 15, 2023

📌 Commit bd17322 has been approved by WaffleLapkin

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 Mar 15, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 15, 2023
…s, r=WaffleLapkin

error-msg: impl better suggestion for `E0532`

Fixes rust-lang#106862

No test as there is already a test which is nearly identical to the example in the linked issue.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 16, 2023
…s, r=WaffleLapkin

error-msg: impl better suggestion for `E0532`

Fixes rust-lang#106862

No test as there is already a test which is nearly identical to the example in the linked issue.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 16, 2023
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#108875 (rustdoc: fix type search for `Option` combinators)
 - rust-lang#108971 (error-msg: impl better suggestion for `E0532`)
 - rust-lang#109139 (rustdoc: DocFS: Replace rayon with threadpool and enable it for all targets)
 - rust-lang#109151 (Assert def-kind is correct for alias types)
 - rust-lang#109158 (error-msg: expand suggestion for `unused_def` lint)
 - rust-lang#109166 (make `define_opaque_types` fully explicit)
 - rust-lang#109171 (Some cleanups in our normalization logic)
 - rust-lang#109180 (Unequal → Not equal)
 - rust-lang#109185 (rustdoc: remove `std::` from primitive intra-doc link tooltips)
 - rust-lang#109192 (Mention UEFI target promotion in release notes for 1.67.0)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1385a32 into rust-lang:master Mar 16, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 16, 2023
@Ezrashaw Ezrashaw deleted the E0532-better-binding-names branch March 17, 2023 09:30
# for free to join this conversation on GitHub. Already have an account? # 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

E0532 could perhaps chose better binding names?
4 participants