[cfe-commits] [PATCH] VisitInitListExpr

[Zhongxing Xu]

<Not certain if we need E->IngoreParens()->getInit().

Perhaps. We'd better have a consistent Parenthesis handle scheme. The
current one looks ad hoc (or I haven't get it from the code?).


>
> +      NodeSet Tmp;
> +      Visit(Init, Pred, Tmp);
> +
> +      // We do not allow state splitting during Initializer visiting.
> +      assert(Tmp.size() == 1);
>
> I'm fine with this for an initial patch (keeps things simple), but this is
> a bogus limitation that is easily broken.  For example, initializers that
> contain function calls may easily have state-splitting.  We allow
> state-splitting when processing CallExprs and ObjCMessageExprs; this is no
> different.  The difference here is that initializer lists might be very
> long, so using recursive calls to "Aux" functions probably isn't a good
> idea.  We can manually do this recursion by maintaining a stack of NodeSets
> (ala llvm::SmallVector?) and processing it like a worklist.  This is a
> little complicated, so it should go in a second patch.


Yeah, a worklist is better than recursion.


>
>
> +
> +  if (T->isStructureType()) {
> +    // FIXME: to be implemented.
> +    MakeNode(Dst, E, Pred, state);
> +    return;
> +  }
>
> Isn't the case for structs exactly the same as for arrays?  I don't see
> anything in the above code that is specific to arrays.


Should be yes.


>
>
> +
> +  if (Loc::IsLocType(T) || T->isIntegerType()) {
> +    // FIXME: to be implemented.
> +    MakeNode(Dst, E, Pred, state);
> +    return;
> +  }
>
> Is this possible?  Can InitListExpr have one of these types?


There is one example in test/Analysis/stack-addr-ps.c. In the last function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081030/fbf538d5/attachment.html>