[cfe-dev] AST Representation of Conversions

[Eli Friedman]

On Tue, Jul 28, 2009 at 9:14 PM, Douglas Gregor<dgregor at apple.com> wrote:
>
> On Jul 28, 2009, at 7:16 PM, Eli Friedman wrote:
>
>> On Tue, Jul 28, 2009 at 4:00 PM, Douglas Gregor<dgregor at apple.com> wrote:
>>>
>>> ImplicitConversionSequence is quite heavy, and I don't think that
>>> clients need that much information. It seems to me that we could get
>>> away with adding an enum (covering all the kinds of conversions you
>>> mentioned above) and a declaration (that points to a constructor or
>>> conversion function). The Expr class already has enough spare bits to
>>> store the enum, so CastExpr (and its descendents) would only have to
>>> grow by a single pointer. That, IMO, is an acceptable trade-off, since
>>> we'll be making CodeGen easier for C and possibly for C++.
>>
>> I can't see how a pointer which would always be null in C code could
>> possibly make CodeGen easier for C code...
>
> The enum makes CodeGen easier for C code, since we don't need to figure out
> what kind of conversion to perform. The constructor/conversion function
> pointer, of course, won't help C at all.

Right... but the point is, you're proposing adding a pointer to
CastExpr that's completely useless for C code.  It might be that it's
not worth the effort to avoid here, but we've been trying to avoid
bloating the C AST exclusively for the benefit of C++ code.

>> Note that we can always recalculate the appropriate declaration; it
>> might make sense to put the relevant code into the AST so it can be
>> shared between Sema and CodeGen.
>
>
> It's expensive to recalculate, because you'll have to perform overload
> resolution again. That's far too much code to move into AST.

Oh, I see.  Then scratch that.

-Eli