PR c++/54401 - Confusing diagnostics about type-alias at class scope
authordodji <dodji@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 7 Dec 2012 17:05:19 +0000 (17:05 +0000)
committerdodji <dodji@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 7 Dec 2012 17:05:19 +0000 (17:05 +0000)
commit8f0104ff80f5fb9912b841855c4f9122d95b4c84
treeaf6cdc4cf6c72a86564a7cf29400fa2d1fcac8da
parent84eb345f94feb9369b492b6d6faf2fd3a66d8b26
PR c++/54401 - Confusing diagnostics about type-alias at class scope

Consider this invalid example given in the PR, where T is not defined:

     1 template<typename>
     2 struct X {
     3     using type = T;
     4 };

g++ yields the confusing diagnostics:

test.cc:3:10: error: expected nested-name-specifier before 'type'
    using type = T;
          ^
test.cc:3:10: error: using-declaration for non-member at class scope
test.cc:3:15: error: expected ';' before '=' token
    using type = T;
               ^
test.cc:3:15: error: expected unqualified-id before '=' token

I think this is because in cp_parser_member_declaration we tentatively
parse an alias declaration; we then have a somewhat meaningful
diagnostic which alas is not emitted because we are parsing
tentatively.  As the parsing didn't succeed (because the input is
invalid) we try to parse a using declaration, which fails as well; but
then the diagnostic emitted is the one for the failed attempt at
parsing a using declaration, not an alias declaration.  Oops.

The idea of this patch is to commit the tentative parse when we see
the '=' token in the alias-declaration.  That way any error encounter
after that token is reported to the user.

We are now getting the following output:

    test.cc:3:18: erreur: expected type-specifier before â€˜T’
 using type = T;
      ^
    test.cc:3:18: erreur: â€˜T’ does not name a type

I don't really like the "before 'T'" there, but I think we maybe could
revisit the format of what cp_parser_error emits in general, now that
we have caret diagnostics;  We could maybe do away with the "before T"
altogether?

In the mean time, it seems to me that this patch brings an improvement
over what we already have in trunk, and the issue above could be
addressed separately.

Tested on x86_64-unknown-linux-gnu against trunk.

gcc/cp/

* parser.c (cp_parser_alias_declaration): Commit to tentative
parse when see the '=' token.  Get out if the type-id is invalid.
Update function comment.
(cp_parser_member_declaration): Don't try to parse a using
declaration if we know that we expected an alias declaration; that
is, if we see the '=' token after the identifier.

gcc/testsuite/

* g++.dg/cpp0x/alias-decl-28.C: New test.
* g++.dg/cpp0x/alias-decl-16.C: Update.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194306 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/cp/ChangeLog
gcc/cp/parser.c
gcc/testsuite/ChangeLog
gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C [new file with mode: 0644]