This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A question about cp/pt.c:type_unification_real

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    ::   ::         CodeSourcery    ::

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]