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

[Douglas Gregor]

On Jan 27, 2011, at 1:44 AM, Abramo Bagnara wrote:

> 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.

Eliminated the replicated nodes would be wonderful; the replication is a holdover from the days when we had a strict ownership model of expressions with no notion of sharing.

	- Doug