[Bug c++/54401] New: Missing diagnostics about type-alias at class scope

[Bug c++/54401] New: Missing diagnostics about type-alias at class scope

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

             Bug #: 54401
           Summary: Missing diagnostics about type-alias at class scope
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gdr@gcc.gnu.org


The following simple and innocuous (ill-formed)
programs leads g++ in C++11 mode to produce a
very misleading unhelpful diagnostic:

gauss[3:28]% cat b.C                                                
template<typename>
struct X {
   using type = T;
};

When compiled with g++ in C++11 mode, I get:

gauss[3:32]% ~/gnu/bin/g++ -std=c++11 b.C                     
b.C:3:10: error: expected nested-name-specifier before 'type'
    using type = T;
          ^
b.C:3:10: error: using-declaration for non-member at class scope
b.C:3:15: error: expected ';' before '=' token
    using type = T;
               ^
b.C:3:15: error: expected unqualified-id before '=' token


(you need monospace fonts to make sense of the carets in the diagnostics)

The real problem is that `T' is undeclared (presumably a template
type parameter.)  

I would expect the compiler to accept the syntax as a valid 
alias declaration, and complain later that `T' isn't in scope.
In short it should be semantics error, not a parse error.

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-08-29
     Ever Confirmed|0                           |1

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[dodji at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |dodji at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |dodji at gcc dot gnu.org
                   |gnu.org                     |

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

--- Comment #1 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-09-28 15:43:34 UTC ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01906.html

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[dodji at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

--- Comment #2 from Dodji Seketeli <dodji at gcc dot gnu.org> 2012-12-07 17:05:40 UTC ---
Author: dodji
Date: Fri Dec  7 17:05:19 2012
New Revision: 194306

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194306
Log:
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.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C

[Bug c++/54401] Missing diagnostics about type-alias at class scope

[dodji at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Dodji Seketeli <dodji at gcc dot gnu.org> 2012-12-07 17:15:20 UTC ---
This should be fixed in trunk (4.8)