[cfe-dev] InitListExpr::getSyntacticForm and C++

Abramo Bagnara abramo.bagnara at gmail.com
Tue Jan 25 22:09:32 PST 2011


Il 25/01/2011 23:39, John McCall ha scritto:
>>
>> I'm not sure to read you right: are you saying that you believe it is an
>> accident the lack of CXXConstructExpr/ImplicitCastExpr for class typed
>> initializer or the presence of implicit casts for initializer with
>> builtin types?
> 
> The only reason that the syntactic InitListExpr has implicit casts in it is
> that we try to reuse the syntactic ILE as the semantic ILE.  You should
> not count on the syntactic ILE ever having such casts.

This lead to problems implementing important services on clang...

The clang AST basic design is to have a data structure that, together
with complete syntactical info, stores also rich info about what is
happening "under the hood" (implicit cast, shadow decl, cxx construct
expr, implicit this, implicit member expr, etc.).

As far as I can see this is always true (despite a single understandable
notable exception being absence of destructor implicit invocation) and
recent wonderful adding of lvalue to rvalue casts is a further step in
this very same path.

The effect to not follow this design pattern for syntactic list expr is
the impossibility to implement things like to count the syntactically
present constructor invocation (needed for Halstead metrics, the student
job that originated my email).

Take as an example this code:

class C {
public:
  C();
  C(int a);
};

int a = 3;
C v[10] = {1, 2, [2 ... 5] = 3.0};

If we look into semantic form we will find 4 constructor invocation for
3.0 instead of 1, OTOH if we look into syntactic form we will not find
the constructor invocation.

This is only an example of what would become impossible to do, but I
hope that the general point is clear: I think that to have init list
expr syntactic form that not follow general design patterns is a bad
thing (think to have an init list expr of type int[4] that have as
elements uncasted float literals, etc.)



More information about the cfe-dev mailing list