Implict casts disappeared from syntactic init list expressions in C++

[Abramo Bagnara via cfe-commits]

Ping (I still need your feedback so that I can open a properly
documented issue on bugzilla).

Il 09/10/2015 09:58, Abramo Bagnara ha scritto:
> Il 08/10/2015 23:36, Richard Smith ha scritto:
>> There are some other open problems in this area:
>>
>> - RecursiveASTVisitor on nested InitListExprs is currently worst-case
>> exponential time because it walks the syntactic and semantic forms
>> separately
>> - Tools such as "find all references to this function" need the semantic
>> form of every initializer, whether or not that initializer is actually
>> used for the initialization (it might be overridden through the use of a
>> designator)
>> - ...
>>
>> Having thought about this for a while, I think the right answer is this:
>>
>> The only difference between the syntactic and semantic forms of an
>> InitListExpr should be designated initializers and brace elision. In all
>> other respects, the syntactic and semantic forms should be identical --
>> in particular, both should contain the results of performing the
>> relevant initialization sequences on the list elements, and we should
>> extend the syntactic form to include the implicit initializations for
>> trailing elements.
> 
> I suppose that you are proposing to include implicit initializations for
> trailing elements to have in syntactic form all the references.
> 
> Note however that what you suggest is not enough when extending C++ with
> designated initializers (like gcc and clang do, at least partially).
> 
> This is an example:
> 
> struct f1 {
>   f1();
> };
> struct f2 {
>   f2();
> };
> 
> struct s {
>   f1 x;
>   f2 y;
> };
> 
> s v = { .x = f1() };
> 
> You can easily imagine a similar example where the same effect is
> obtained with an array (three elements, first and third are explicitly
> initialized).
> 
> IMHO it is better to avoid to add implicit fields/array elements
> initialization in syntactic form and let tools that need to collect
> implicit constructor reference to find a different way, e.g. scanning
> semantic form for ImplicitValueInitExpr children of InitListExpr
> (unfortunately currently not present (by mistake I guess, but I'd like
> to hear your opinion) as you can observe from -ast-dump output of
> previous example).
> 
>> With that in hand, we should make RecursiveASTVisitor visit /only/ the
>> syntactic form. The semantic ("simplified") form should only be used in
>> places where we want to know the semantic effect of the initialization
>> (after applying the designated initialization overriding rules and
>> inserting the elided braces), and is always derivable in a fairly
>> straightforward fashion from the syntactic form.
>>
>> I think that's largely what you were suggesting below. Do you agree?
> 
> Apart the doubt about the detail above, your design matches perfectly my
> suggestions.
> 
> 


-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com