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

Suggest using an appropriate keyword for struct and enum #94996

Conversation

TaKO8Ki
Copy link
Member

@TaKO8Ki TaKO8Ki commented Mar 16, 2022

closes #75770

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 16, 2022
@rust-highfive
Copy link
Collaborator

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 16, 2022
@rust-log-analyzer

This comment has been minimized.

@TaKO8Ki TaKO8Ki changed the title Suggest using a appropriate keyword for struct and enum Suggest using an appropriate keyword for struct and enum Mar 16, 2022
Comment on lines 8 to 11
help: consider using `enum` instead of `struct`
|
LL | #[derive(enum)]
| ~~~~
Copy link
Member

Choose a reason for hiding this comment

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

Seems like this shouldn't happen, the suggested replacement has 0 chance to work at all.

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 fixed it.

Comment on lines +9 to +12
help: consider using `enum` instead of `struct`
|
LL | pub enum NotStruct {
| ~~~~
Copy link
Member

Choose a reason for hiding this comment

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

I'm not entirely sure if we should be as trigger happy as proposed here about suggesting a different ADT type. I feel like it is much more likely that an ADT body will contain mistakes compared to user having specified a wrong kind of ADT.

Here it feels like the user was much more likely to just have forgetten to specify a type : _ for whatever reason. Though I could still see us making a suggestion as proposed here if there was at least one variant with data. That is in cases like these:

pub struct NotStruct {
    Variant,
    Variant2(u8),
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with nagisa's comment. I think that for a case as ambiguous as these we might be better served by pointing at all the relevant places and let the user figure what they wanted. That could be done for cases like this one by adding a label to the struct keyword saying "while parsing this struct".

Copy link
Contributor

Choose a reason for hiding this comment

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

The comment above is still valid. I would prefer to simplify the logic and "just" add a span_label pointing at the item type being parsed. The likelihood of false positives is too high as it is.

@@ -1176,13 +1178,14 @@ impl<'a> Parser<'a> {
}

/// Parses an enum declaration.
fn parse_item_enum(&mut self) -> PResult<'a, ItemInfo> {
fn parse_item_enum(&mut self, start_span: Span) -> PResult<'a, ItemInfo> {
Copy link
Member

Choose a reason for hiding this comment

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

start_span seems a little misnomer here, given that the span begins at the enum or struct keyword, rather than covering the entire item (i.e. including the qualifiers such as pub). Maybe something like keyword_span would work better?

Ok(_) => {
let mut err = this.struct_span_err(
enum_field_start_span.to(this.prev_token.span),
"the enum cannot have a struct field declaration",
Copy link
Member

Choose a reason for hiding this comment

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

Diagnostics in parser largely follow a “expected ...” style of messages. The suggested wording would likely be more consistent with the rest of the diagnostics coming from the parser.

Suggested change
"the enum cannot have a struct field declaration",
"expected an `enum` variant, found a field",

let (fields, recovered) = self.parse_record_struct_body(
"union",
generics.where_clause.has_where_token,
None,
Copy link
Member

Choose a reason for hiding this comment

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

If we're handling structs, we should also handle unions.

);
err.span_suggestion_verbose(
start_span,
"consider using `struct` instead of `enum`",
Copy link
Member

Choose a reason for hiding this comment

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

Hm, an union could also make sense here, wouldn't it? While it is comparatively much rarer, looking to define an enum like this may very well be thinking of an union in the first place.

Suggested change
"consider using `struct` instead of `enum`",
"consider defining a `struct` or an `union` instead of an `enum`",

Not entirely sure how or if span_suggestion can provide multiple alternative replacements, though.

Copy link
Member

Choose a reason for hiding this comment

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

It might very well be that this suggestion is largely superfluous with the improved error message.

@nagisa
Copy link
Member

nagisa commented Mar 20, 2022

I'm going to pass this on to @estebank for a further review, since they have a better grasp over the overall direction of diagnostics in Rust.

@nagisa
Copy link
Member

nagisa commented Mar 20, 2022

r? @estebank

@rust-highfive rust-highfive assigned estebank and unassigned nagisa Mar 20, 2022
@estebank
Copy link
Contributor

Let's make sure we have tests to avoid regressing on knock down errors (let's have a struct and enum with multiple variants and fields to see that we only emit a single error for them).

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 22, 2022

@estebank
Ok! I am going to improve it.

@apiraino
Copy link
Contributor

apiraino commented Apr 7, 2022

Switching review labels until PR is ready again for review, thanks!

@rustbot author

@rustbot rustbot 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 Apr 7, 2022
@TaKO8Ki TaKO8Ki force-pushed the suggest-using-appropriate-keyword-for-struct-and-enum branch from c0d2c11 to f49601d Compare April 10, 2022 02:48
@bors
Copy link
Contributor

bors commented Apr 28, 2022

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

@Dylan-DPC Dylan-DPC 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 Jul 18, 2022
notriddle added a commit to notriddle/rust that referenced this pull request Sep 26, 2022
…nion-ident, r=estebank

Add a label to struct/enum/union ident name

Based on rust-lang#94996 (comment)
cc: ``@estebank``
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 27, 2022
…on-ident, r=estebank

Add a label to struct/enum/union ident name

Based on rust-lang#94996 (comment)
cc: `@estebank`
@TaKO8Ki TaKO8Ki closed this Sep 27, 2022
@TaKO8Ki TaKO8Ki deleted the suggest-using-appropriate-keyword-for-struct-and-enum branch September 27, 2022 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve syntax diagnostics or suggestions with enum vs struct
9 participants