https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- (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!
