[Bug c++/64758] New: [C++11] Give better error message when name of enum's base type cannot be resolved

[Bug c++/64758] New: [C++11] Give better error message when name of enum's base type cannot be resolved

[zeratul976 at hotmail dot com]

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

            Bug ID: 64758
           Summary: [C++11] Give better error message when name of enum's
                    base type cannot be resolved
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zeratul976 at hotmail dot com

For the following invalid code:


  enum Waldo : uint32_t {   // oops, forgot to include <stdint.h>
    A, B
  };


GCC's error message is: 


  test.cpp:1:6: error: use of enum ‘Waldo’ without previous declaration
   enum Waldo : uint32_t {
        ^
  test.cpp:1:12: error: expected unqualified-id before ‘:’ token
   enum Waldo : uint32_t {
              ^

This error doesn't really match the problem. A much better error would be:


  test.cpp:1:6: error: use of ‘uint32_t’ without previous declaration
   enum Waldo : uint32_t {
                ^
>From gcc-bugs-return-474644-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 23 23:04:29 2015
Return-Path: <gcc-bugs-return-474644-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18923 invoked by alias); 23 Jan 2015 23:04:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18869 invoked by uid 48); 23 Jan 2015 23:04:21 -0000
From: "zeratul976 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved
Date: Fri, 23 Jan 2015 23:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zeratul976 at hotmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64758-4-xPrrhxDqyj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64758-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64758-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02638.txt.bz2
Content-length: 252

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd758

--- Comment #1 from Nathan Ridge <zeratul976 at hotmail dot com> ---
By comparison, clang's error is:

  test.cpp:1:14: error: unknown type name 'uint32_t'
  enum Waldo : uint32_t {
               ^

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-24
     Ever confirmed|0                           |1

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It got worse (maybe better) in GCC 9.4.0 and 10+:
<source>:3:14: error: found ':' in nested-name-specifier, expected '::'
    3 |   enum Waldo : uint32_t {   // oops, forgot to include <stdint.h>
      |              ^
      |              ::
<source>:3:8: error: 'Waldo' has not been declared
    3 |   enum Waldo : uint32_t {   // oops, forgot to include <stdint.h>
      |        ^~~~~
<source>:3:25: error: expected unqualified-id before '{' token
    3 |   enum Waldo : uint32_t {   // oops, forgot to include <stdint.h>
      |                         ^

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=59423
                 CC|                            |gnubugzilla at drewnoakes dot com

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 59423 has been marked as a duplicate of this bug. ***

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For this code:

enum class foo : bar { baz };
auto x = foo::baz;

We give:

e.C:1:6: warning: elaborated-type-specifier for a scoped enum must not use the
‘class’ keyword
    1 | enum class foo : bar { baz };
      | ~~~~ ^~~~~
      |      -----
e.C:1:16: error: found ‘:’ in nested-name-specifier, expected ‘::’
    1 | enum class foo : bar { baz };
      |                ^
      |                ::
e.C:1:12: error: ‘foo’ has not been declared
    1 | enum class foo : bar { baz };
      |            ^~~
e.C:1:22: error: expected unqualified-id before ‘{’ token
    1 | enum class foo : bar { baz };
      |                      ^
e.C:2:10: error: ‘foo’ has not been declared
    2 | auto x = foo::baz;
      |          ^~~


Every one of these diagnostics is the result of bad error recovery from the
initial problem.

The warning is just nonsense. The first error is a bad recovery, we should not
assume it's a bested-name-specifier, we should assume it's an enum-base with an
undeclared type in the type-specifier-seq. The remaining errors are because we
failed to do anything useful with the bad enum definition.

I suggest that we should notice that ": bar" is bad, give an error about "bar"
being undeclared, and then act as though no enum-base was present for the rest
of the compilation. All the other diagnostics should vanish at that point.

We won't complain about a bogus elaborared-type-specifier that isn't present.
We won't say 'foo' is undeclared. We won't complain about expecting an
unqualified-id (when one is actually present, just not one we recognize), and
we won't complain about foo::baz being undeclared.

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #4)
> I suggest that we should notice that ": bar" is bad, give an error about
> "bar" being undeclared, and then act as though no enum-base was present for
> the rest of the compilation. All the other diagnostics should vanish at that
> point.

That seems to be what Clang does:

e.C:1:18: error: unknown type name 'bar'
enum class foo : bar { baz };
                 ^
1 error generated.

There's no error about foo::baz, presumably because after realising the
enum-base was bad, they just skipped it and still compiled the enumerator-list
successfully.

EDG gives pretty much the same errors as GCC though.

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #4)
> For this code:
> 
> enum class foo : bar { baz };
> auto x = foo::baz;
> 
> We give:
> 
> e.C:1:6: warning: elaborated-type-specifier for a scoped enum must not use
> the ‘class’ keyword
>     1 | enum class foo : bar { baz };
>       | ~~~~ ^~~~~
>       |      -----
[...]
> The warning is just nonsense.

I'm now convinced that this warning does more harm than good. It's supposed to
be a pedwarn for this case:

enum D { };
extern enum class D d;

But that's just ill-formed, we should reject it outright, as Clang and EDG do.

And for the later errors, we should not assume the user is trying to write
foo::bar when **that's not going to be valid anyway**! We should assume they're
trying to write exactly what they wrote, with a base-type of bar, and diagnose
that 'bar' is not declared.

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barry.revzin at gmail dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 109222 has been marked as a duplicate of this bug. ***

[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamil_tym at wp dot pl

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 115371 has been marked as a duplicate of this bug. ***