fix issue-144595

[bb1yd]

I close the previous PR because it's too messy

relevant issue:#144595

I fix this issue by calling look_ahead to check if the user write a name field in the tuple struct, then try to recover after calling parse_ty

[rustbot]

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, parser
• compiler, parser expanded to 73 candidates
• Random selection from 16 candidates

[qaijuang]

No test ?

[bb1yd]

I have added a test. Thank you.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

FWIW I don't think your original PR was "too messy", or whatever that meant. No need to close and open a new one 🙂

Can you change the output to more closely represent the output suggested in #144595?

Let's keep

expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:`

and add help messages to it. Not replace the error entirely. I think it's much more likely that the user made a typo than that they were mistaken about the difference between tuple and regular structs.

Some meta nits: please try to minimize irrelevant changes to keep the PR easier to review.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[bb1yd]

Oops, they are changes from early iterations and I forgot to change them back.

[bb1yd]

@rustbot ready

[bb1yd]

I undo irrelevant changes and change the error message to expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:` and use diagnostic struct to generate help message.

[mejrs]

You can't hard code an error message like this, it's far too brittle. Please just append the help message to the existing error.

View changes since the review

[bb1yd]

The original error is created in parse_paren_comma_seq (it didn't find a comma). I'm not sure how to capture that error.

[mejrs]

It's in ret.

So you can do something like...

self.parse_paren_comma_seq(|p| { 
   // stuff
})
 .map(|(r, _)| r)
.map_err(|mut e| {
    e.help("oh no");
    e
})

That way you also don't end up indenting the entirety of parse_paren_comma_seq, which should help with the messyness of this pr :)

[bb1yd]

I understand, but in this approach parse_paren_comma_seq will exit at the first colon and we can only report the first name field error.

[bb1yd]

Or do you want the code to continue parse the tuple field and find every name field in map_err?

[mejrs]

Generally rustc does try to "keep going" and report more errors if possible. So, I think "yes". I guess it depends on what it ends up looking like.