https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102775
Bug ID: 102775
Summary: Error recovery in the C++ parser should use fix-it
hints
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Blocks: 16663
Target Milestone: ---
The scope of this is probably big and I have no idea how feasible it is, but
...
Consider the example in PR 102771:
template<typename.. T> void f(T...) { }
And the errors:
vart.C:1:18: error: expected nested-name-specifier before ‘.’ token
1 | template<typename.. T> void f(T...) { }
| ^
vart.C:1:18: error: expected ‘>’ before ‘.’ token
vart.C:1:29: error: variable or field ‘f’ declared void
1 | template<typename.. T> void f(T...) { }
| ^
vart.C:1:31: error: ‘T’ was not declared in this scope
1 | template<typename.. T> void f(T...) { }
| ^
After the first two errors g++ is just confused, and so we get the unhelpful
"declared void" error (PR 102774).
We should add a fix-it for the '...' token (PR 102771), and then it would be
awesome if the parser acted as though that was what it had seen. Replace the
two bogus '.' tokens with '...' and carry on. The rest of the function would
parse OK! We would not get the "declared void" error and we would not get the
"'T' was not declared in this scope" error.
For the example in PR 16663 comment 9, if we assumed that the undeclared
"misspelled" really was intended to be the "mispelled" type that is in scope,
the rest of the function declaration would parse OK! We would not print the
next three errors.
For the example in PR 102773, if we had fix-its for those errors and pretended
that's what the code had said, we would only print 3 errors not 10.
Generally, our error recovery is often poor. It's helpful to try and keep going
after an error, so that code with multiple problems will print multiple errors,
and the user can fix them all before compiling again. This shortens the
edit-compile-debug cycle, and is good. But when we print four errors for a
single function declaration, because of a single misplaced character, that's
not good.
Any time we offer a fix-it it's likely we have made an educated guess about
what the code really meant. We should make the parser continue as though that
was actually what the code said. Obviously this won't always be correct, but in
my experience our fix-it hints are correct far more often than they're wrong.
Maybe sometimes it would make the diagnostics worse, but the "declared void"
cases are already bad anyway (although PR 102774 would help there).
We show great fix-it hints to users, we should use them as feedback to the
parser too.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16663
[Bug 16663] Poor parse error recovery with mispelled type in function
declaration
