From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4935 invoked by alias); 5 Oct 2011 21:08:59 -0000 Received: (qmail 4926 invoked by uid 22791); 5 Oct 2011 21:08:58 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 21:08:45 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p95L8iFw031790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 17:08:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p95L8iP7014235; Wed, 5 Oct 2011 17:08:44 -0400 Received: from [0.0.0.0] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p95L8hB4004468; Wed, 5 Oct 2011 17:08:43 -0400 Message-ID: <4E8CC75A.5090900@redhat.com> Date: Wed, 05 Oct 2011 21:24:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ed Smith-Rowland <3dw4rd@verizon.net> 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> In-Reply-To: <4E8C7DF0.9030809@verizon.net> 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/msg00385.txt.bz2 On 10/05/2011 11:55 AM, Ed Smith-Rowland wrote: > + int num_parms = TREE_VEC_LENGTH (parameter_list); > + if (num_parms != 1) > + ok = false; > + else > + { > + tree parm_list = TREE_VEC_ELT (parameter_list, 0); > + tree parm = INNERMOST_TEMPLATE_PARMS (parm_list); This is backwards; you want to do INNERMOST_TEMPLATE_PARMS before looking at the number of parms or pulling out the one at index 0. > +struct GTY(()) tree_userdef_literal { > + struct tree_common common; I think you can use tree_base instead of tree_common here, since you aren't using TREE_TYPE or TREE_CHAIN. > One thing doesn't work. Earlier I had said that friend declarations failed. Not true. What fails is defining the function body in the class definition. The function is simply not recorded. I'm trying to track this down but pointers would be helpful. If I write the function body outside the class definition friend works perfectly. > About friends. The lookup for user-defined literal operators isn't ADL. They are a lot like normal functions because of the suffix-id as opposed to operator<< in this regard. Thus a friend literal operator should be accessible both as an explicit operator call and via a literal. Both are tested and except as noted above about inline defs the tests pass. A function that is only declared in a friend declaration can only be found by ADL, so that doesn't sound like a failure to me; it sounds like it's working the way it should. However, if you declare the function earlier and then define it in the friend declaration it ought to work. Jason