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

[Abramo Bagnara]

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.

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?