From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10014 invoked by alias); 29 Oct 2002 13:56:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9925 invoked from network); 29 Oct 2002 13:56:25 -0000 Received: from unknown (HELO mozart.inet.co.th) (203.150.14.100) by sources.redhat.com with SMTP; 29 Oct 2002 13:56:25 -0000 Received: from users.sourceforge.net (IDENT:8V1U1HzLUjzEJFtPH9rvaHCXvjkbokFd@TruPPP0B007.inet.co.th [203.151.125.7]) by mozart.inet.co.th (8.9.1a/8.9.0) with ESMTP id UAA06725; Tue, 29 Oct 2002 20:56:16 +0700 (GMT+0700) Message-ID: <3DBE945A.5070101@users.sourceforge.net> Date: Tue, 29 Oct 2002 05:56:00 -0000 From: Kriang Lerdsuwanakij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Mitchell CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ PATCH] Class template instantiation according to core issue 287. References: <35940000.1035786424@warlock.codesourcery.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg01760.txt.bz2 Mark Mitchell wrote: > >> Bootstrapped and tested on i686-pc-linux-gnu with no regression. >> OK to commit to main trunk? > > > This is a regression, right? If so, commit it to both the mainline > and the branch. It's only a regression in mainline. Other regressions in the branch appear to unrelate to this issue. So I am going to commit it only on mainline. > >> + /* Add T to CLASSTYPE_DECL_LIST of TYPE which will be used >> + later during class template instantiation. >> + When FRIEND_P is zero, T can be member data, member >> + function, nested type, or member class template. >> + When FRIEND_P is nonzero, T is either friend class or >> + friend function. */ > > > Reword this to talk abut the kinds of tree nodes: > > T can be a non-static data member (FIELD_DECL), a member function > (FUNCTION_DECL), a nested class (RECORD_TYPE), etc. > > I want us to start thinking of the tree structure as strongly typed. > > Also, what about non-static data members? Both static and non-static data members are handled in the case TYPE_FIELDS. They are VAR_DECL and FIELD_DECL respectively. --Kriang