https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105840
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For a destructor we do a bit better, but it could still be improved.
struct A {
~A();
};
struct C {
~A();
};
105840.C:14:3: error: declaration of ‘~A’ as member of ‘C’
14 | ~A();
| ^
Yes, the formal reason the code is invalid is that ~A cannot be a member of C,
but the actual reason is that the author made a typo or forgot to change it
after copy&paste.
Maybe similar wording should be used for the constructor and destructor cases,
and a fix-it suggesting changing the "A" to "C" would be nice.
Clang gives a user-friendly message, but no fix-it:
105840.C:6:3: error: expected the class name after '~' to name the enclosing
class
~A();
^
1 error generated.
For a similar case where A hasn't been declared yet, we don't do so well:
struct Foo {
~Fo();
};
105840.C:2:6: error: expected class-name before ‘(’ token
2 | ~Fo();
| ^
This is just a typo, but because "Fo" hasn't been declared prior to this, we
give a very different diagnostic compared to the "~A" case. It would be nice if
this also used similar wording to the other examples, and also gave a fix-it.
Clang does quite well here:
105840.C:2:4: error: undeclared identifier 'Fo' in destructor name
~Fo();
^~
Foo
1 error generated.
Although I don't see any reason why Clang gives such different wording for the
"undeclared identifier" and "expected [...] to name the enclosing class" cases.
In both cases the problem is a destructor with a name that isn't the enclosing
class. Whether the name has been declared or not is irrelevant. I think Barry's
suggestion in comment 2 (or something like it) would be good for destructors
too, whether or not the "unrelated class 'A'" has previously been declared.
