[Bug c++/107178] New: Diagnosis for colon vs semi-colon in a member function declaration

[Bug c++/107178] New: Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178

            Bug ID: 107178
           Summary: Diagnosis for colon vs semi-colon in a member function
                    declaration
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following code emits a poor diagnosis:

struct T {};

struct S {
    T foo():
};

<source>:4:7: error: bit-field 'T S::foo()' has non-integral type 'T (S::)()'
    4 |     T foo():
      |       ^~~

https://godbolt.org/z/39ME3K6TE

At least for the case of a member function declaration, a better diagnosis
would probably be ideal.


For T foo():, clang emits:

<source>:5:1: error: expected '(' or '{'
};
^


For T foo:, clang emits:

<source>:5:1: error: expected expression
};
^
<source>:5:3: error: expected '}'
};
  ^
<source>:3:10: note: to match this '{'
struct S {
         ^
<source>:5:3: error: expected ';' after struct
};
  ^
  ;

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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 ....

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178

--- Comment #2 from Jeremy R. <llvm at rifkin dot dev> ---
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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-07
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

[redi at gcc dot gnu.org]

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!

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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!