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

Abramo Bagnara via cfe-commits cfe-commits at lists.llvm.org
Fri Oct 9 00:58:20 PDT 2015


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


More information about the cfe-commits mailing list