[cfe-dev] Getting DecompositionDecl from BindingDecl

[George Karpenkov via cfe-dev]

> On Mar 29, 2018, at 4:37 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> On 29 March 2018 at 15:08, George Karpenkov via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hi Richard,
> 
> Thanks for your reply!
> 
> > Can you say more about why the static analyzer might want to map from a BindingDecl to a DecompositionDecl?
> 
> One thing I couldn’t figure out is how to figure out whether a given binding represents a global.
> But turns out that for my use case turns out that somehow was not required.
> 
> I'm still not sure why you'd want to know that.

Turns out I don’t actually need this for my specific use case.
But in general the analyzer often has different behavior for globals, as analysis runs on a single translation unit,
and has to assume that any other translation unit can do whatever it wants to the globals.

> 
> > BindingDecls should generally just be treated wrappers around some lvalue expression.
> 
> Right, yes, that unfortunately forces quite a lot of special-casing on us, as suddenly in many places where we expected only a VarDecl we know get a BindingDecl.
> 
> What kind of places?

Quite a few of them.
E.g. in https://reviews.llvm.org/D44956 liveness analysis had to be re-done for binding declarations (if all BindingDecls had an underlying VarDecl the code change would have been around four lines instead).
The memory handling has to be extended to introduce a special class for dealing with binding declarations
(again, would have been avoided if they had an underlying VarDecl) [e.g. partial fix just to avoid the crash is in https://reviews.llvm.org/D44183]

In my understanding, clang itself has the same problem with strange special cases like not being able to capture a binding in a lambda.

> 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'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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180330/06f42dbc/attachment.html>