Improve parser diagnostics
This pr fixes https://github.com/rust-lang/rust/issues/93867 and contains a couple of diagnostics related changes to the parser.
Here is a short list with some of the changes:
- don't suggest the same thing that is the current token
- suggest removing the current token if the following token is one of the suggestions (maybe incorrect)
- tell the user to put a type or lifetime after where if there is none (as a warning)
- reduce the amount of tokens suggested (via the new eat_noexpect and check_noexpect methods)
If any of these changes are undesirable, i can remove them, thanks!
Recover missing comma after match arm
If we're missing a comma after a match arm expression, try parsing another pattern and a following `=>`. If we find both of those, then recover by suggesting to insert a `,`.
Fixes#80112
Move conditions out of recover/report functions.
`Parser` has six recover/report functions that are passed a boolean, and
nothing is done if the boolean has a particular value.
This PR moves the tests outside the functions. This has the following effects.
- The number of lines of code goes down.
- Some `use` items become shorter.
- Avoids the strangeness whereby 11 out of 12 calls to
`maybe_recover_from_bad_qpath` pass `true` as the second argument.
- Makes it clear at the call site that only one of
`maybe_recover_from_bad_type_plus` and `maybe_report_ambiguous_plus` will be
run.
r? `@estebank`
Rollup of 6 pull requests
Successful merges:
- #89685 (refactor: VecDeques Iter fields to private)
- #97172 (Optimize the diagnostic generation for `extern unsafe`)
- #97395 (Miri call ABI check: ensure type size+align stay the same)
- #97431 (don't do `Sized` and other return type checks on RPIT's real type)
- #97555 (Source code page: line number click adds `NaN`)
- #97558 (Fix typos in comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Optimize the diagnostic generation for `extern unsafe`
This PR does the following about diagnostic generation when parsing foreign mod:
1. Fixes the FIXME about avoiding depending on the error message text.
2. Continue parsing when `unsafe` is followed by `{` (just like `unsafe extern {...}`).
3. Add test case.
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.
Signed-off-by: David Wood <david.wood@huawei.com>
Parse expression after `else` as a condition if followed by `{`
Fixes#49361.
Two things:
1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics 😅
2. Do we even want to show the "wrap in braces" case? I would assume most of the time the "add an `if`" case is the right one.
