in which .. is suggested for erroneous ... in struct field patterns

[zackmdavis]

Resolves#46718. Supersedes #46721.

r? @petrochenkov

[petrochenkov]

@bors r+

[bors]

📌 Commit d40197c has been approved by petrochenkov

[petrochenkov]

@zackmdavis@estebank
This issue, like many others, fits into more general pattern of "confusable tokens".
Each token T has set of tokens that are likely to be used instead of it by mistake {U1, U2, U3, ...}, either due to similarity to other languages, or keyboard layout, or other reasons.
In all contexts where we expect T, don't expect Ui and actually see Ui we should accept it, report a non-fatal error recommending T instead, and continue parsing.

This PR is a very typical diagnostic PR adding an ad hoc custom error for a single token in a single context ignoring the larger picture.
For example, the situation ".. but not ..." can arise in other contexts, like expressions + the "confusable" relation is symmetric, so we can also recommend ... in situations "... but not ..", e.g. variadic functions in FFI.

It would be more useful to fix this generically, e.g. to add something like fn expect_token(token::DotDot) used in all contexts expecting .. that would check for tokens confusable with .. automatically.
The main problem with doing this generically is that the "don't expect Ui" may be non-trivial and require lookaheads and duplicated logic, but it's probably still possible to come up with some usable interface.

Even without generic approach, fixing all contexts (including symmetry) for a specific pair of tokens (like .. vs ...) would be nice.

[bors]

⌛ Testing commit d40197c with merge 3bee2b4...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing 3bee2b4 to master...