Bug 94057 - [9 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
Summary: [9 Regression] -std=gnu++20 causes failure naming nested templated class sinc...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 10.0
: P2 normal
Target Milestone: 10.0
Assignee: Marek Polacek
URL:
Keywords: rejects-valid
: 65943 84186 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-03-05 17:39 UTC by Romain Geissler
Modified: 2021-08-23 10:34 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-03-06 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Geissler 2020-03-05 17:39:36 UTC
Hi,

The following snippet fails with gcc trunk and with gcc 9 if I compile with -std=gnu++20, but not with -std=gnu++17. gcc <= 8 or any clang version happily compiles it whatever -std value I use.

template <typename T> class A
{
    template <typename... Types> class B
    {
        B(const A<T>::B<Types...>&) = default;
    };
};

It reads:

<source>:5:23: error: 'typename A<T>::B' names 'template<class T> template<class ... Types> class A<T>::B', which is not a type
    5 |         B(const A<T>::B<Types...>&) = default;
      |                       ^~~~~~~~~~~
<source>:5:34: error: expected unqualified-id before '&' token
    5 |         B(const A<T>::B<Types...>&) = default;
      |                                  ^
<source>:5:34: error: expected ')' before '&' token
    5 |         B(const A<T>::B<Types...>&) = default;
      |          ~                       ^
      |                                  )
<source>:5:34: error: constructors may not be ref-qualified
<source>:5:34: error: expected ';' at end of member declaration
    5 |         B(const A<T>::B<Types...>&) = default;
      |                                  ^
      |                                   ;
<source>:5:35: error: expected unqualified-id before ')' token
    5 |         B(const A<T>::B<Types...>&) = default;
      |                                   ^
Compiler returned: 1

Cheers,
Romain
Comment 1 Jakub Jelinek 2020-03-06 07:45:37 UTC
Started with r9-4536-g96c35892bea68ac180f19079cf08fea3b6cda0a8
Comment 2 Jakub Jelinek 2020-03-12 11:58:58 UTC
GCC 9.3.0 has been released, adjusting target milestone.
Comment 3 Marek Polacek 2020-03-12 17:27:29 UTC
Not relate to parameter packs.  Also happens with normal member functions:

template <typename T> class A {
  template <typename U> class B {
    B(A<T>::B<U>&);
    void fn(A<T>::B<U> &);
  };
};
Comment 4 Marek Polacek 2020-03-12 17:43:59 UTC
The root cause isn't the C++20 feature it seems.  The following version with explicit 'typename' is rejected, but compiles fine with clang/icc:

template <typename T> class A {
  template <typename U> class B {
    B(typename A<T>::B<U>&);
    void fn(typename A<T>::B<U> &);
  };
};
Comment 5 Marek Polacek 2020-03-12 23:16:15 UTC
(We accept it when the template keyword is added: "typename A<T>::template B<U>".)
Comment 6 GCC Commits 2020-03-26 22:47:34 UTC
The master branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:517f5356bb0ca717f51e937be880e38a828edbf7

commit r10-7403-g517f5356bb0ca717f51e937be880e38a828edbf7
Author: Marek Polacek <polacek@redhat.com>
Date:   Wed Mar 18 19:28:14 2020 -0400

    c++: DR1710, template keyword in a typename-specifier [PR94057]
    
    Consider
    
      template <typename T> class A {
        template <typename U> class B {
          void fn(typename A<T>::B<U>);
        };
      };
    
    which is rejected with
    error: 'typename A<T>::B' names 'template<class T> template<class U> class A<T>::B', which is not a type
    whereas clang/icc/msvc accept it.
    
    "typename A<T>::B<U>" is a typename-specifier.  Sadly, our comments
    don't mention it anywhere, because the typename-specifier wasn't in C++11;
    it was only added to the language in N1376.  Instead, we handle it as
    an elaborated-type-specifier (not a problem thus far).   So we get to
    cp_parser_nested_name_specifier_opt which has a loop that breaks if we
    don't see a < or ::, but that means we can -- tentatively -- parse even
    B<U> which is not a nested-name-specifier (it doesn't end with a ::).
    
    I think this should compile because [temp.names]/4 says: "In a qualified-id
    used as the name in a typename-specifier, elaborated-type-specifier,
    using-declaration, or class-or-decltype, an optional keyword template
    appearing at the top level is ignored.", added in DR 1710.  Also see
    DR 1812.
    
    This issue on its own is not a significant problem or a regression.
    However, in C++20, the typename here becomes optional, and so this test
    is rejected in C++20, but accepted in C++17:
    
      template <typename T> class A {
        template <typename U> class B {
          void fn(A<T>::B<U>);
        };
      };
    
    Here we morph A<T>::B<U> into a typename-specifier, but that happens
    in cp_parser_simple_type_specifier and we never handle it as above.
    To fake the template keyword I'm afraid we need to use cp_parser_template_id
    with template_keyword_p=true as in the patch below.  The tricky thing
    is to avoid breaking concepts.
    
    To handle DR 1710, I made cp_parser_nested_name_specifier_opt assume that
    when we're naming a type, the template keyword is present, too.  That
    revealed a bug: DR 1710 also says that the template keyword can be followed
    by an alias template, but we weren't prepared to handle that.  alias-decl?.C
    exercise this.
    
    gcc/cp:
    
            DR 1710
            PR c++/94057 - template keyword in a typename-specifier.
            * parser.c (check_template_keyword_in_nested_name_spec): New.
            (cp_parser_nested_name_specifier_opt): Implement DR1710, optional
            'template'.  Call check_template_keyword_in_nested_name_spec.
            (cp_parser_simple_type_specifier): Assume that a <
            following a qualified-id in a typename-specifier begins
            a template argument list.
    
    gcc/testsuite:
    
            DR 1710
            PR c++/94057 - template keyword in a typename-specifier.
            * g++.dg/cpp1y/alias-decl1.C: New test.
            * g++.dg/cpp1y/alias-decl2.C: New test.
            * g++.dg/cpp1y/alias-decl3.C: New test.
            * g++.dg/parse/missing-template1.C: Update dg-error.
            * g++.dg/parse/template3.C: Likewise.
            * g++.dg/template/error4.C: Likewise.
            * g++.dg/template/meminit2.C: Likewise.
            * g++.dg/template/dependent-name5.C: Likewise.
            * g++.dg/template/dependent-name7.C: New test.
            * g++.dg/template/dependent-name8.C: New test.
            * g++.dg/template/dependent-name9.C: New test.
            * g++.dg/template/dependent-name10.C: New test.
            * g++.dg/template/dependent-name11.C: New test.
            * g++.dg/template/dependent-name12.C: New test.
            * g++.dg/template/dependent-name13.C: New test.
            * g++.dg/template/dr1794.C: New test.
            * g++.dg/template/dr314.C: New test.
            * g++.dg/template/dr1710.C: New test.
            * g++.dg/template/dr1710-2.C: New test.
            * g++.old-deja/g++.pt/crash38.C: Update dg-error.
Comment 7 Marek Polacek 2020-03-26 22:50:24 UTC
Fixed.  I don't think I want to backport this one.  To make it work with G++ 9, add the template keyword.
Comment 8 Jonathan Wakely 2020-11-10 17:38:05 UTC
*** Bug 65943 has been marked as a duplicate of this bug. ***
Comment 9 Jonathan Wakely 2021-08-23 10:34:10 UTC
*** Bug 84186 has been marked as a duplicate of this bug. ***