[cfe-dev] Getting DecompositionDecl from BindingDecl

[George Karpenkov via cfe-dev]

Hi Richard,

Thanks for your reply!

> OK, but a BindingDecl isn't a global (it's not even an object, just a symbolic name for an expression). It might represent an lvalue expression that denotes a global, but that global will be either a DecompositionDecl or an implicitly-introduced holding variable, both of which you can readily identify as being globals.

Right, sure, but I don’t have a convenient way to find that DecompositionDecl from a given BindingDecl,
and sometimes I need to act based on the BindingDecl alone.

> It seems to me that the problem here is actually that the CFG is mismodeling BindingDecls. If it expanded them to their expression, I don't think you'd need any special handling here.

Could you clarify what you mean? For the analyzer, the CFG is just used to model the control flow, and to separate it into statements.
Given a statement, the analyzer processes it just based on AST.
What would “expand” mean here? Defining a kind of intermediate representation the analyzer operates on?
>  
> In my understanding, clang itself has the same problem with strange special cases like not being able to capture a binding in a lambda.
> 
> You can't capture a binding in a lambda because a binding is not a variable, per the C++ standard's rules. This is not a clang problem.
>> The intended operational semantics are that when you see a DeclRefExpr naming a BindingDecl, you evaluate its associated subexpression.
> 
> Right, but what we also need to do is to figure out what to do with a BindingDecl when we see it on its own.
> Also to evaluate all its subexpressions we need to introduce special casing for BindingDecl’s, as they are not VarDecl’s anymore.
> 
> I think you may be misunderstanding the semantic model we're using here. BindingDecls have nothing to do with VarDecls; they're a completely different kind of thing with completely different semantics, just like EnumConstantDecls are a completely different kind of thing with completely different evaluation semantics.

Yes, yes, of course I understand that Clang implements the standard correctly.
I was just saying that the wording of c++17 standard is a bit unfortunate for us,
since it means a lot of special casing.

> 
> Simple example:
> 
> struct A { int x, y; };
> 
> void f(A a) {
>   auto [v, w] = a;
>   use(v, w);
> }
> 
> This gives you a DecompositionDecl, which is a kind of VarDecl, of type A, initialized with 'a'. Let's call that 'e'.
> It also gives you two BindingDecls, which are symbolic names for the expressions 'e.x' and 'e.y'.
> So the evaluation semantics of the above function are as if you wrote:
> 
> void f(A a) {
>   A e = a;
>   use(e.x, e.y);
> }

Right, thanks for the clarification!
In my mind, the final version was equivalent to

void f(A a) {
  auto &v = a.x;
  auto &w = a.y;
  use(v, w);
}

but I guess that’s not the case.
Was a different model chosen in the standard due to performance considerations?

> 
> That's what the CFG for the above function should represent.

Sorry, I’m not sure what do you mean here: from my understanding, CFG does not transform AST inside statements (apart from maybe tiny syntactic things).

> The BindingDecls should not even show up, except as sugar so that clients who care can know that the 'e.x' expression was /written as/ 'v'.
>> I'd imagine this is best modeled by generating CFG nodes for the subexpression on each occurrence of such a DeclRefExpr, much like (IIRC) is done for CXXDefaultArgExpr and CXXDefaultInitExpr. That seems like it would not require too many special cases elsewhere.
>> 
>> (Perhaps the static analyzer needs more than that in order to produce more user-friendly diagnostics?)
> 
> We are not even there yet for structured bindings, just trying to make the analyzer understand them.
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180330/2a5cb9f7/attachment.html>