[cfe-dev] Adding type source info to ImplicitValueInitExpr.

[John McCall]

On Jan 18, 2010, at 5:24 PM, Abramo Bagnara wrote:

> Il 18/01/2010 22:33, John McCall ha scritto:
>> On Jan 18, 2010, at 3:21 AM, Enea Zaffanella wrote:
>>> The attached patch adds (optional) type source info to class
>>> ImplicitValueInitExpr: the type source info will have a valid value
>>> if the ImplicitValueInitExpr results from __builtin_offsetof
>>> constructs.
>> I think we'd rather not take this. The primary use of
>> ImplicitValueInitExpr does not involve a type written in the source;
>> in fact, it involves no source code at all. This patch is useful
>> solely because of the current implementation of __builtin_offsetof.
>> That implementation is terrible, and it's long past time for
>> __builtin_offsetof to get its own AST class. When that happens, this
>> patch will be unnecessary.
> 
> We have thought to have __builtin_offsetof as a separate AST class and
> this certainly has some advantages (mainly the fact to have the right
> source range and some cleaning) and we definitely agree this would be a
> good thing, but the patch from Enea try to solve a problem that is
> orthogonal to this:
> 
> __builtin_offsetof(struct s, f) is currently expressed in the AST as
> 
> UnaryOperator(offsetof, MemberExpr(UnaryOperator(deref,
> ImplicitValueInitExpr(PointerType(RecordType())))))
> 
> As you can see, also if we transform this in:
> 
> OffsetOf(MemberExpr(UnaryOperator(deref,
> ImplicitValueInitExpr(PointerType(RecordType())))))
> 
> as wished in PR5390, we still have an ImplicitValueInitExpr where we
> have to insert an appropriate TypeSourceInfo.
> 
> Unless you want to replace the use of ImplicitValueInitExpr in offsetof
> expression (with what?), I think that patch from Enea should be accepted.

Syntactically, __builtin_offsetof does not have any subexpressions;  I would prefer that OffsetOfExpr (or whatever) follow this and simply be a leaf node with a complex internal structure, much like its input from the parser.

> But, also if you hope to replace ImplicitValueInitExpr too someday, it
> is not better to have a better intermediate suboptimal implementation
> while waiting for the definitive solution to be implemented (after we
> have clear how this should be), is it?

I'm fine with workarounds up to the point that they start affecting unrelated parts of the system.

If you need something now and don't want to change __builtin_offsetof's representation that drastically, perhaps changing the ImplicitValueInitExpr to a CStyleCastExpr of 0?  Those at least naturally have a written type.

John.