This is the mail archive of the
mailing list for the GCC project.
Re: A question about cp/pt.c:type_unification_real
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Kazu Hirata <kazu at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, mark at codesourcery dot com, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Wed, 09 Aug 2006 09:45:41 +0100
- Subject: Re: A question about cp/pt.c:type_unification_real
- References: <200608082013.k78KDLvu007484@sparrowhawk.codesourcery.com>
Kazu Hirata wrote:
I have a question about cp/pt.c:type_unification_real.
However, "args" appears to be a parameter list, too. For example,
type_unification_real contains code like:
Even more confusing is:
arg = TREE_VALUE (args);
if (!TYPE_P (arg))
Can a function argument be a type?
type_unification_real is used for three things,
* For function call deduction-like things. ARGS will be a list of expressions
for a function call (this will affected by Sandra's changes).
* For partial specialization ordering. ARGS will be a function parameter list.
* for type unification. ARGS will be a function type's arg types. (this is the
call from 'unify'.)
As you can see all these uses currently represent those distinct types as a
TREE_LIST. Sandra will change the first one to a CALL_EXPR. The second and
third will be changed by your modifications.
In the first two of these cases, it is called from type_unification. You'll see
that that can push the return type onto the start of arg & parms lists, so even
there an element of ARGS can be a type.
It may be that type_unification_real needs cloning into two variants for the
distinct type of ARGS. the pushing of the return type certainly needs
separating out (as a distinct argument probably).
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery
firstname.lastname@example.org :: http://www.planetfall.pwp.blueyonder.co.uk