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

Abramo Bagnara abramo.bagnara at gmail.com
Thu Jan 27 01:44:01 PST 2011


Il 26/01/2011 20:11, John McCall ha scritto:
> On Jan 25, 2011, at 10:09 PM, Abramo Bagnara wrote:
>> 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.).
> 
> Absolutely.  This generally works because the "under the hood" behavior
> can be treated as extra information layered on top of the syntax tree.
> Unfortunately, this is not necessarily true of initializer lists, where the semantic
> form can be structured and ordered quite differently from the syntactic form.
> Therefore we fall back to having two different views of the information, one of
> which isn't always faithful to the syntax and one of which isn't always faithful
> to the semantics.
> 
> I'm sorry if you've been skating by so far on the assumption that the syntactic
> form will always contain all the relevant semantic information.  If you have an
> actual proposal for how to integrate these views, I think that would be interesting.

I'd think that simply to add needed implicit nodes around the
initializer expr while still in syntactic form and then reuse them in
the semantic form is the perfect solution.

Not only this solves the problem above, but also it is far more time and
memory efficient than current implementation.

If you pass to

clang -cc1 -ast-dump t.cc

the following source

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

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

you'll see that the generated identical nodes are replicated many times
without any sharing.

Too trivial to be true? I'm missing something, am not I?




More information about the cfe-dev mailing list