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

resolve: further improvements to "try using the enum's variant" diagnostic #77855

Merged

Conversation

davidtwco
Copy link
Member

Follow-up on #77341 (comment).

This PR improves the diagnostic modified in #77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly.

I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like .. in those spans, which doesn't seem worth it).

r? @estebank

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 12, 2020
@davidtwco davidtwco force-pushed the pr-77341-follow-up-non-constructable-variants branch from d5f9e40 to 16e16aa Compare October 14, 2020 10:12
Copy link
Contributor

@estebank estebank left a comment

Choose a reason for hiding this comment

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

I like the change, but have a couple of nitpicks. What do you think?

Comment on lines 71 to 146
help: try using one of the enum's variants
help: try using the enum's variant which have fields
|
LL | let _: E = E::Unit;
| ^^^^^^^
help: try using one of the enum's variants which have fields
|
LL | let _: E = (E::Fn(/* fields */));
| ^^^^^^^^^^^^^^^^^^^^^
LL | let _: E = (E::Struct { /* fields */ });
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Copy link
Contributor

Choose a reason for hiding this comment

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

What about

help: you might have meant to use the following enum variant(s)
  |
help: alternatively, the following enum variants are also available
  |

Copy link
Member Author

Choose a reason for hiding this comment

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

I've updated the PR to use this wording.

Comment on lines 1385 to 1393
let needs_placeholder = |def_id: DefId, kind: CtorKind| {
let has_no_fields =
self.r.field_names.get(&def_id).map(|f| f.is_empty()).unwrap_or(false);
match kind {
CtorKind::Const => false,
CtorKind::Fn | CtorKind::Fictive if has_no_fields => false,
_ => true,
}
}
}
};
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be useful to either include the field names in the suggestion (instead of /*fields*/) with some placeholder per field, or to have a span pointing at the def, otherwise you are forcing people to consult the docs/code to fix the issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added a note that points at the definition of the enum, this seemed more straightforward than adjusting the suggestions while still having the desired effect.

This commit improves the diagnostic modified in rust-lang#77341 to
suggest not only those variants which do not have fields, but those with
fields (by suggesting with placeholders).

Signed-off-by: David Wood <david@davidtw.co>
This commit improves the tuple struct case added in rust-lang#77341
so that the context is mentioned in more of the message.

Signed-off-by: David Wood <david@davidtw.co>
@davidtwco davidtwco force-pushed the pr-77341-follow-up-non-constructable-variants branch from 16e16aa to f897162 Compare October 15, 2020 17:06
@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Oct 16, 2020

📌 Commit f897162 has been approved by estebank

@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 Oct 16, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 16, 2020
…nstructable-variants, r=estebank

resolve: further improvements to "try using the enum's variant" diagnostic

Follow-up on rust-lang#77341 (comment).

This PR improves the diagnostic modified in rust-lang#77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly.

I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like `..` in those spans, which doesn't seem worth it).

r? @estebank
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 16, 2020
…nstructable-variants, r=estebank

resolve: further improvements to "try using the enum's variant" diagnostic

Follow-up on rust-lang#77341 (comment).

This PR improves the diagnostic modified in rust-lang#77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly.

I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like `..` in those spans, which doesn't seem worth it).

r? @estebank
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 16, 2020
Rollup of 10 pull requests

Successful merges:

 - rust-lang#75209 (Suggest imports of unresolved macros)
 - rust-lang#77547 (stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union')
 - rust-lang#77827 (Don't link to nightly primitives on stable channel)
 - rust-lang#77855 (resolve: further improvements to "try using the enum's variant" diagnostic)
 - rust-lang#77900 (Use fdatasync for File::sync_data on more OSes)
 - rust-lang#77925 (Suggest minimal subset features in `incomplete_features` lint)
 - rust-lang#77971 (Deny broken intra-doc links in linkchecker)
 - rust-lang#77991 (Bump backtrace-rs)
 - rust-lang#77992 (instrument-coverage: try our best to not ICE)
 - rust-lang#78013 (Fix sidebar scroll on mobile devices)

Failed merges:

r? `@ghost`
@bors bors merged commit 75ef735 into rust-lang:master Oct 16, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 16, 2020
@davidtwco davidtwco deleted the pr-77341-follow-up-non-constructable-variants branch October 16, 2020 23:15
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants