public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
Date: Thu, 26 Mar 2020 22:47:34 +0000	[thread overview]
Message-ID: <bug-94057-4-L69snugExo@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94057-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

  parent reply	other threads:[~2020-03-26 22:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-94057-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` jakub at gcc dot gnu.org
2020-03-12 17:27 ` mpolacek at gcc dot gnu.org
2020-03-12 17:43 ` mpolacek at gcc dot gnu.org
2020-03-12 23:16 ` mpolacek at gcc dot gnu.org
2020-03-26 22:47 ` cvs-commit at gcc dot gnu.org [this message]
2020-03-26 22:50 ` mpolacek at gcc dot gnu.org
2020-11-10 17:38 ` [Bug c++/94057] [9 " redi at gcc dot gnu.org
2021-08-23  0:13 ` pinskia at gcc dot gnu.org
2021-08-23 10:34 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-94057-4-L69snugExo@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).