propagate the error from parsing enum variant to the parser and emit out

[lyming2007]

While parsing enum variant, the error message always disappear
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case #103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix #103869

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eholk (or someone else) soon.

Please see the contribution instructions for more information.

[eholk]

Suggested change

	err.help("enum variants can be `Variant` or `Variant = <integer>` or `Variant(Type)` or `Variant { field: Type }`");
	err.help("enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type)`, or `Variant { field: Type }`");

I wonder if we should write Variant(Type) as Variant(Type, ...) or Variant(Type1, ..., TypeN), and similarly for the struct case? Or maybe Variant(Types) and Variant { fields: types }. Basically, I wonder if it's worth trying to also show that enum variants can have multiple fields or is showing one enough?

[eholk]

Thanks for the contribution! Overall, this looks pretty good. I posted a couple of questions about minor tweaks to the hint message, but I think this is a big improvement.

One suggestion I'd add for future PRs. In the commit description, rather than just saying "fix #103869," it'd be helpful if you could include a brief summary of the bug you're fixing (just a sentence or two and maybe a short code example if it makes sense) and how your PR fixes it (this isn't always going to be that interesting, but especially if there's something subtle about the fix this can be really helpful). As a reviewer that helps a lot because it saves me a step in having to pull up the issue and read the description first.

Thanks again! I'll give you a little time in case you want to respond to any of my review comments, but I don't think I'd consider any of them blockers.

[lyming2007]

Thanks for the contribution! Overall, this looks pretty good. I posted a couple of questions about minor tweaks to the hint message, but I think this is a big improvement.

One suggestion I'd add for future PRs. In the commit description, rather than just saying "fix #103869," it'd be helpful if you could include a brief summary of the bug you're fixing (just a sentence or two and maybe a short code example if it makes sense) and how your PR fixes it (this isn't always going to be that interesting, but especially if there's something subtle about the fix this can be really helpful). As a reviewer that helps a lot because it saves me a step in having to pull up the issue and read the description first.

Thanks again! I'll give you a little time in case you want to respond to any of my review comments, but I don't think I'd consider any of them blockers.
Thank you Eric for the feedback! I've updated the commit description. Here is it:
While parsing enum variant, the error message always disappear
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case #103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix #103869

[eholk]

Thanks, looks good!

@bors r+

[bors]

📌 Commit 0e19fb9 has been approved by eholk

It is now in the queue for this repository.