Re: [RFA] Add method overload resolution to expression parser

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Keith> +static struct type *
Keith> +make_params (int num_types, struct type **param_types)
Keith> +{
[...]
Keith> +  make_cleanup (free_param_types, type);
Keith> +  return type;
Keith> +}

Daniel> And this is even more confusing... how does this cleanup eventually
Daniel> get run?  We shouldn't leak it back to the top level.  And I suspect
Daniel> that since nothing ever copies types, if this type makes it into the
Daniel> value history we're going to have a problem.

I think this can be addressed by changing the TYPE_INSTANCE case to deal
with the cleanups.

Daniel> I also wonder why TYPE_INSTANCE is necesary.  All it seems to do is
Daniel> construct the temporary type.  Can't we do that in the parser,
Daniel> instead, and use UNOP_CAST?

My reading is that it has to do with the lifetime of a type.

This implementation defers creation of the temporary function type to
the point where it is used.  IIUC, which I hope I do :-), this temporary
type can't really leak out of the TYPE_INSTANCE code.  That is, it is
constructed and used to look up an actual function or method (which has
its own type).

If we used UNOP_CAST then we would have to make a long-lived temporary
type, not only because the type would have to live at least from parsing
through the end of the life of the parsed expression, but also because
the result of the cast would have that temporary type, and thus it would
be capturable.

This would not be as big a deal if the type GC work were finished, but
that is still pending.

Tom