[cfe-dev] Getting DecompositionDecl from BindingDecl

[George Karpenkov via cfe-dev]

Hi Richard,

Thanks for your reply!

> On Mar 30, 2018, at 8:49 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> 
> 
> 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.
> 
> Can you give an example?

Let’s say a structured binding is written into, and then some function is called, and then we read from that binding again.
If it was global, we have to assume any function call can invalidate it, but if it’s local and it wasn’t passed as a parameter,
chances are it will remain the same.

> It was chosen because it matches the semantic model desired by the designers of the feature. For example, you can't handle bitfields if you model structured bindings as reference variables.
> 
> This was a somewhat controversial decision, but it doesn't look like it's going to be reversed.
>> 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).
> 
> IIRC, the CFG expands CXXDefaultArgExprs and CXXDefaultInitExprs; this case is analogous to those.

Yes, you are right; To be honest, I wasn’t previously familiar with that part of the codebase.
Yet still, those are very simple replacements, and IIRC those are the only two.

Supporting structured bindings would be indeed easier if we could have a simpler AST,
could you give an advice on what would be an equivalent AST we should rewrite to?

Would producing a MemberExpr reading from the struct at *use* time be completely semantically equivalent?
My previous impression was that for structured bindings load from the struct happens when the binding occurs,
not when the actual read is performed.
[though of course such rewrites would impede producing good diagnostic messages for the user]

>> 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>
> _______________________________________________
> 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/20180402/769b5cd8/attachment.html>