From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20847 invoked by alias); 12 Oct 2011 05:06:04 -0000 Received: (qmail 20836 invoked by uid 22791); 12 Oct 2011 05:06:03 -0000 X-SWARE-Spam-Status: No, hits=4.0 required=5.0 tests=AWL,BAYES_00,BOTNET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vms173005pub.verizon.net (HELO vms173005pub.verizon.net) (206.46.173.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Oct 2011 05:05:49 +0000 Received: from [192.168.1.11] ([unknown] [96.244.95.87]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LSX001SBSTB0AQ2@vms173005.mailsrvcs.net> for gcc-patches@gcc.gnu.org; Wed, 12 Oct 2011 00:05:36 -0500 (CDT) Message-id: <4E95201F.4020004@verizon.net> Date: Wed, 12 Oct 2011 06:51:00 -0000 From: Ed Smith-Rowland <3dw4rd@verizon.net> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-version: 1.0 To: Jason Merrill Cc: gcc-patches Subject: Re: [C++-11] User defined literals References: <4E6F6A1C.90305@verizon.net> <4E7008DA.6090703@redhat.com> <4E76FBBB.6050601@verizon.net> <4E77B002.50804@redhat.com> <4E77F549.6000704@verizon.net> <4E78F475.8070303@redhat.com> <4E8C7DF0.9030809@verizon.net> <4E8CC75A.5090900@redhat.com> <4E909588.3000801@verizon.net> <4E90D97F.9060506@redhat.com> <4E922BEF.1080100@verizon.net> <4E947505.3050404@redhat.com> <4E947562.5090505@redhat.com> In-reply-to: <4E947562.5090505@redhat.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit 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 X-SW-Source: 2011-10/txt/msg00955.txt.bz2 On 10/11/2011 12:57 PM, Jason Merrill wrote: > On 10/11/2011 12:55 PM, Jason Merrill wrote: >> On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote: >>> Does cp_parser_identifier (parser) *not* consume the identifier token? >> >> I'm pretty sure it does. It does. >> >> Does it work to only complain if !cp_parser_parsing_tentatively? > > I suppose not, if you got no complaints with cp_parser_error. > > Jason > > cp_parser_operator(function_id) is simply run twice in cp_parser_unqualified_id. Once inside cp_parser_template_id called at parser.c:4515. Once directly inside cp_parser_unqualified_id at parser.c:4525. cp_parser_template_id never succeeds with literal operator templates. I find that curious. But I haven't looked real hard and the things do get parsed somehow.