https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77540
Bug ID: 77540
Summary: Confusing diagnostics due to stray comma in
ctor-init-list
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct A { };
struct B : A
{
B() : A(), // N.B. erroneous comma here
{
}
typedef int C;
C c;
};
This says:
e.cc:11:3: error: ‘C’ does not name a type
C c;
^
e.cc: In constructor ‘B::B()’:
e.cc:6:3: error: expected identifier before ‘{’ token
{
^
This doesn't help find the error in the code.
The first diagnostic is a consequence of the second one, so a user who tries to
fix the errors in the order they appear (usually the best approach to fixing
compiler errors) is stuck, because C certainly *is* a type from the user's
perspective. They have to ignore the "does not name a type" error and fix the
next one instead. If there are several uses of C then there could be several
errors before the important "expected identifier" one.
The second diagnostic is quite vague, and could have a better location. A
better diagnostic, with fixit hint, would be:
e.cc: In constructor ‘B::B()’:
e.cc:6:3: error: expected identifier before ‘{’ token. Remove the comma?
B() : A(), // N.B. erroneous comma here
^
Ideally this would also be printed first, but I realise that the "does not name
a type" error comes when compiling the class body, which happens before the
constructor body. I assume the parser consumes everything up to the semi-colon
after the typedef declaration as part of the constructor body, and so the
declaration isn't seen before the uses of C.
