From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116471 invoked by alias); 6 Dec 2018 16:33:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 116457 invoked by uid 89); 6 Dec 2018 16:33:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=88373, Hx-languages-length:2105 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Dec 2018 16:33:26 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EEA3987628 for ; Thu, 6 Dec 2018 16:33:24 +0000 (UTC) Received: from redhat.com (ovpn-124-120.rdu2.redhat.com [10.10.124.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 43E085D6A6; Thu, 6 Dec 2018 16:33:24 +0000 (UTC) Date: Thu, 06 Dec 2018 16:33:00 -0000 From: Marek Polacek To: GCC Patches , Jason Merrill Subject: C++ PATCH for c++/88373, wrong parse error with ~ Message-ID: <20181206163316.GM21364@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2018-12/txt/msg00376.txt.bz2 This patch fixes a bogus parse error with ~ in a template-argument-list. We have S> and cp_parser_template_argument just tries to parse each argument as a type, id-expression, etc to see what sticks. When it sees ~value, it tries to parse it using cp_parser_class_name (because of the ~), which ends up calling cp_parser_lookup_name, looking for "value", but finds nothing. Since it's an unqualified-id followed by <, we treat "~value" as a template name function. It isn't followed by "(args)", so we simulate parse error. As a consequence of this error, the parsing of the outermost template-id S fails. The problem is that when we're looking up the name in cp_parser_class_name, tag_type is typename_type, which means bindings that do not refer to types are ignored, so the variable template "value" isn't found and we're toast. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2018-12-06 Marek Polacek PR c++/88373 - wrong parse error with ~. * parser.c (cp_parser_template_name): Check tag_type for none_type. * g++.dg/cpp2a/fn-template19.C: New test. diff --git gcc/cp/parser.c gcc/cp/parser.c index ac19cb4b9bb..2f55855ce9f 100644 --- gcc/cp/parser.c +++ gcc/cp/parser.c @@ -16579,7 +16579,8 @@ cp_parser_template_name (cp_parser* parser, if (!found && (cxx_dialect > cxx17) && !scoped_p - && cp_lexer_next_token_is (parser->lexer, CPP_LESS)) + && cp_lexer_next_token_is (parser->lexer, CPP_LESS) + && tag_type == none_type) { /* [temp.names] says "A name is also considered to refer to a template if it is an unqualified-id followed by a < and name lookup finds diff --git gcc/testsuite/g++.dg/cpp2a/fn-template19.C gcc/testsuite/g++.dg/cpp2a/fn-template19.C new file mode 100644 index 00000000000..1d6b43bb7ce --- /dev/null +++ gcc/testsuite/g++.dg/cpp2a/fn-template19.C @@ -0,0 +1,11 @@ +// PR c++/88373 +// { dg-do compile } +// { dg-options "-std=c++2a" } + +template +constexpr T value = T {}; + +template +struct S {}; + +using U = S >;