From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12371 invoked by alias); 9 Oct 2011 23:19:46 -0000 Received: (qmail 12363 invoked by uid 22791); 9 Oct 2011 23:19:45 -0000 X-SWARE-Spam-Status: No, hits=4.2 required=5.0 tests=AWL,BAYES_00,BOTNET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vms173017pub.verizon.net (HELO vms173017pub.verizon.net) (206.46.173.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 09 Oct 2011 23:19:23 +0000 Received: from [192.168.1.11] ([unknown] [96.244.95.87]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LST00J89NFZTS81@vms173017.mailsrvcs.net> for gcc-patches@gcc.gnu.org; Sun, 09 Oct 2011 18:19:12 -0500 (CDT) Message-id: <4E922BEF.1080100@verizon.net> Date: Sun, 09 Oct 2011 23:46: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> In-reply-to: <4E90D97F.9060506@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/msg00709.txt.bz2 On 10/08/2011 07:15 PM, Jason Merrill wrote: > On 10/08/2011 07:25 PM, Ed Smith-Rowland wrote: >> Also, In spite of the documentation cp_parser_template_parameter_list >> returns a TREE_VEC not a TREE_LIST. This happens inside >> end_template_parm_list called inside the former. So parameter_list is a >> TREE_VEC, parm_list is a TREE_LIST, parm is a PARM_DECL, etc. > > Ah, I was thinking of template arguments rather than parameters. > You're right, except that INNERMOST_TEMPLATE_PARMS should be just > TREE_VALUE; you are already starting from the innermost parm list if > you use what end_template_parm_list returns. > > Though it occurs to me that push_template_decl_real might be a better > place for this check. > >> I'm still looking for a fix for duplicate errors/warnings coming from >> cp_parser_operator. I tried cp_parser_error and lost the errors. I'll >> look for different code paths for the two invocations and see if I can >> either move something up or see if something is set differently between >> the two that would be useful for a flag. > > One approach would be changing the token stream after the first error > to something that won't produce another error, e.g. changing > token->u.value to be an empty string after you complain about it being > non-empty. Interesting. That one error is the one of the three that does *not* repeat. One idea. the fist error about non-empty string is followed by a consume_token (for the string). Does cp_parser_identifier (parser) *not* consume the identifier token? Is that token left on the stream for second pass? I'll try it and get back. > > Jason >