[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonathan Wakely from comment #3)You'd need to change "T > foo():" to "int foo:N" i.e. change the type, remove the parens, and add a > constant for the size. *and* add a semi-colon!
[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > (In reply to Andrew Pinski from comment #1) > > At least GCC points out the colon and even suggest you started a bitfield > > which is what a colon normally does here > > But not with a function type. My point is that it's invalid however we parse it. It's not a valid bit-field, because of the type. It's not a valid constructor, because it has a return type and the name doesn't match the class. It's not a valid member function, because the colon shouldn't be there. So instead of the most naive parse (an extremely unlikely attempt to define a bit-field with function type) we should consider whether one of the other parses was the most likely, because describing it in those terms will help the highest number of users (as long as the diagnostic we choose doesn't make it *too* difficult to understand for the other, less likely causes). And to look at it another way, the "hamming distance" from "colon instead of semi-colon" to valid code is a single character. The "hamming distance" from "bit-field of function type" to valid code is huge. You'd need to change "T foo():" to "int foo:N" i.e. change the type, remove the parens, and add a constant for the size. It's nowhere near being a valid bit-field!
[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-07 Status|UNCONFIRMED |NEW --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > GCC diagonstic seems reasonable. Only from the most mechanical perspective. > because GCC assumes you started to define a bitfield which is reasonable > assumention really. Not really, because the chances of somebody typing ':' instead of ';' is quite high (they're on the same key on many keyboard layouts) and the chances of somebody trying to define a bit-field with a function type is practically zero. Although the parser just sees "bit-field with function type" we can apply some intelligence and say that's probably not what the user was trying to do. A simple typo is more likely. > At least GCC points out the colon and even suggest you started a bitfield > which is what a colon normally does here But not with a function type.
[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178 --- Comment #2 from Jeremy R. --- The easy solution is to mention both the bitfield and "hey maybe you meant to use a ;"
[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
clang diagnostic is way worse in my mind. It does not even point to the : .
GCC is assuming if you don't have a constructor you have a type and that type
here would be T (S::)()
Take:
```
struct S {
int (*foo)() :
int t;
};
```
Trying to define a pointer to function field foo but used : instead of ;.
GCC diagonstic seems reasonable.
because GCC assumes you started to define a bitfield which is reasonable
assumention really.
clang diagnostic here is never even close to helpful.
At least GCC points out the colon and even suggest you started a bitfield which
is what a colon normally does here
