From patchwork Wed Jun 5 15:45:11 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 249130 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 576762C0089 for ; Thu, 6 Jun 2013 01:45:35 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=Aipht9DeNZs+1Z0Np nMfdX8S7w96rKeoNKw7VnTlvq8e4InSWWyc7OAMsZEiDnOMnsvQc+z4hlunateIq DjguImh/iMNXMmMFAggRM3SfhTKO/CXe4sMA7YlE3lc55WUi1ujy5EZjKzFIwkK9 c1Hzd2tnVeIW9tGubkCCyZ1YJI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=qN2WKj4l6ONHvLsCt3d7O8l 6ELo=; b=aeGpg/ewcj4/MiTHlgqv2eynuMSqT70Kq7FA5+zzJ9o8tux7LxeoBAa /JkOA7YRsCqd0Q9pCHa7oSf+Xx9VL4gp985Q//c+vU3XcbuPGcIXUy3KGTi+D0U+ CLMYODLlxr8hk0RTWc3yYCvkUgf9kxYaYOKhVxdbf5M2khBAMKQQ= Received: (qmail 11759 invoked by alias); 5 Jun 2013 15:45:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 11749 invoked by uid 89); 5 Jun 2013 15:45:28 -0000 X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RCVD_IN_DNSWL_MED, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD, SPF_PASS, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 05 Jun 2013 15:45:27 +0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r55FjOuR021682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Jun 2013 15:45:25 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r55FjNjg002988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jun 2013 15:45:24 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r55FjNWo002985; Wed, 5 Jun 2013 15:45:23 GMT Received: from poldo4.casa (/79.52.233.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Jun 2013 08:45:23 -0700 Message-ID: <51AF5D07.40408@oracle.com> Date: Wed, 05 Jun 2013 17:45:11 +0200 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jason Merrill CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ Patch] PR 51908 References: <51AE8778.8080901@oracle.com> <51AF34DB.6080200@redhat.com> <51AF381E.7030709@oracle.com> <51AF3AE7.50703@redhat.com> <51AF48E0.5060600@redhat.com> In-Reply-To: <51AF48E0.5060600@redhat.com> X-Virus-Found: No Hi, On 06/05/2013 04:19 PM, Jason Merrill wrote: > On 06/05/2013 09:19 AM, Jason Merrill wrote: >> In any case, the commit doesn't seem like the problem. > > Oh, I see, of course it is. The problem is that it commits to all > levels, so that if we happen to be in a nested tentative parse we > can't commit to the inner one without committing to the outer one, > which might not be appropriate. This seems like a basic flaw in our > tentative parsing mechanism. Uhmmm. > What happens if we disable that commit entirely? Not a disaster, I'm attaching a breakdown of the regressions. Essentially no accept invalid or reject valid, but in some cases the quality of the diagnostic worsen a lot and/or becomes more verbose. Now, something else I noticed a few days ago is that for C-style casts things work fine in any case: the difference being that in that case we set parser->in_type_id_in_expr_p to true, something we don't do for static_cast (and the other C++ casts) in cp_parser_postfix_expression. If I do that, then all the testcases we are considering pass with no regressions in the testsuite. Is it something we could do? Patch draft attached. Thanks, Paolo. /////////////////////// FAIL: g++.dg/other/pr39060.C -std=c++98 (test for errors, line 19) FAIL: g++.dg/other/pr39060.C -std=c++98 (test for excess errors) FAIL: g++.dg/other/pr39060.C -std=c++11 (test for errors, line 19) FAIL: g++.dg/other/pr39060.C -std=c++11 (test for excess errors) FAIL: g++.dg/parse/crash50.C -std=c++98 (test for errors, line 5) FAIL: g++.dg/parse/crash50.C -std=c++98 (test for errors, line 9) FAIL: g++.dg/parse/crash50.C -std=c++98 (test for excess errors) FAIL: g++.dg/parse/crash50.C -std=c++11 (test for errors, line 5) FAIL: g++.dg/parse/crash50.C -std=c++11 (test for errors, line 9) FAIL: g++.dg/parse/crash50.C -std=c++11 (test for excess errors) FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for errors, line 4) FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for errors, line 5) FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for errors, line 4) FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for errors, line 5) FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/parse/error7.C -std=gnu++98 (test for errors, line 5) FAIL: g++.dg/parse/error7.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/parse/error7.C -std=gnu++11 (test for errors, line 5) FAIL: g++.dg/parse/error7.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/parse/varmod1.C -std=c++98 (test for excess errors) FAIL: g++.dg/parse/varmod1.C -std=c++11 (test for excess errors) FAIL: g++.dg/template/crash77.C -std=c++98 (test for errors, line 3) FAIL: g++.dg/template/crash77.C -std=c++11 (test for errors, line 3) FAIL: g++.old-deja/g++.brendan/crash61.C -std=c++98 (test for excess errors) FAIL: g++.old-deja/g++.brendan/crash61.C -std=c++11 (test for excess errors) Index: cp/parser.c =================================================================== --- cp/parser.c (revision 199690) +++ cp/parser.c (working copy) @@ -5546,6 +5546,7 @@ cp_parser_postfix_expression (cp_parser *parser, b tree type; tree expression; const char *saved_message; + bool saved_in_type_id_in_expr_p; /* All of these can be handled in the same way from the point of view of parsing. Begin by consuming the token @@ -5560,7 +5561,10 @@ cp_parser_postfix_expression (cp_parser *parser, b /* Look for the opening `<'. */ cp_parser_require (parser, CPP_LESS, RT_LESS); /* Parse the type to which we are casting. */ + saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p; + parser->in_type_id_in_expr_p = true; type = cp_parser_type_id (parser); + parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p; /* Look for the closing `>'. */ cp_parser_require (parser, CPP_GREATER, RT_GREATER); /* Restore the old message. */ Index: testsuite/g++.dg/cpp0x/decltype54.C =================================================================== --- testsuite/g++.dg/cpp0x/decltype54.C (revision 0) +++ testsuite/g++.dg/cpp0x/decltype54.C (working copy) @@ -0,0 +1,26 @@ +// PR c++/51908 +// { dg-do compile { target c++11 } } + +struct foo1 +{ + template + operator decltype(static_cast(nullptr)) () const; +}; + +struct foo2 +{ + template + operator decltype(static_cast(nullptr)) () const; +}; + +struct foo3 +{ + template + operator decltype(static_cast(nullptr)) () const; +}; + +struct foo4 +{ + template + operator decltype(static_cast(nullptr)) () const; +};