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

Douglas Gregor dgregor at apple.com
Thu Jan 27 07:26:28 PST 2011

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

More information about the cfe-dev mailing list