This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Class template instantiation according to coreissue 287.
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Kriang Lerdsuwanakij <lerdsuwa at users dot sourceforge dot net>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 27 Oct 2002 22:27:04 -0800
- Subject: Re: [C++ PATCH] Class template instantiation according to coreissue 287.
--On Saturday, October 26, 2002 09:13:31 PM +0700 Kriang Lerdsuwanakij
After some thought, I decide to implement the proposed resolution
for Core issue 287 (class template instantiation dependencies). Although
the core issue is still under review, it is better than our current ad
hoc solution. With the patch below, members and friends are processed
according to the order of declaration during class template instantiation.
This is the right approach.
A new field CLASSTYPE_DECL_LIST is added to the type lang_specific node
to hold all class declaration in the correct order.
Probably, we should just figure out a way to use TYPE_FIELDs; that's
already got stuff other than FIELD_DECLs on it. And, in a template,
nothing in the middle end should see the TYPE_FIELDs list; those types
should not escape the front end. We do not need to do that optimization
yet, though; correctness first.
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.
+ /* 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?
! /* The TYPE_FIELDS, TYPE_METHODS, and CLASSTYPE_TAGS are all in
! reverse order. Put them in declaration order now. */
/* The following lists are all in reverse order...
Then we do not have list each one explicitly, and keep updating them.
+ TREE_PURPOSE of each TREE_LIST provides the context of declaration
+ and TREE_VALUE is the actual declaration. For friends, TREE_PURPOSE
+ is NULL_TREE. Otherwise it is the class templates itself. */
/* The TREE_PURPOSE of each TREE_LIST node is NULL_TREE for a friend,
and the RECORD_TYPE/UNION_TYPE for the class template otherwise. */
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com