
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2018, at 4:37 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 29 March 2018 at 15:08, George Karpenkov via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br class="">

<br class="">

Thanks for your reply!<br class="">

<span class=""><br class="">

> Can you say more about why the static analyzer might want to map from a BindingDecl to a DecompositionDecl?<br class="">

<br class="">

</span>One thing I couldn’t figure out is how to figure out whether a given binding represents a global.<br class="">

But turns out that for my use case turns out that somehow was not required.</blockquote><div class=""><br class=""></div><div class="">I'm still not sure why you'd want to know that.</div></div></div></div></div></blockquote><div><br class=""></div><div>Turns out I don’t actually need this for my specific use case.</div><div>But in general the analyzer often has different behavior for globals, as analysis runs on a single translation unit,</div><div>and has to assume that any other translation unit can do whatever it wants to the globals.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">

> BindingDecls should generally just be treated wrappers around some lvalue expression.<br class="">

<br class="">

</span>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.</blockquote><div class=""><br class=""></div><div class="">What kind of places?</div></div></div></div></div></blockquote><div><br class=""></div><div>Quite a few of them.</div><div>E.g. in <a href="https://reviews.llvm.org/D44956" class="">https://reviews.llvm.org/D44956</a> 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).</div><div>The memory handling has to be extended to introduce a special class for dealing with binding declarations</div><div>(again, would have been avoided if they had an underlying VarDecl) [e.g. partial fix just to avoid the crash is in <a href="https://reviews.llvm.org/D44183" class="">https://reviews.llvm.org/D44183</a>]</div><div><br class=""></div><div>In my understanding, clang itself has the same problem with strange special cases like not being able to capture a binding in a lambda.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> The intended operational semantics are that when you see a DeclRefExpr naming a BindingDecl, you evaluate its associated subexpression.</div></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><div>Also to evaluate all its subexpressions we need to introduce special casing for BindingDecl’s, as they are not VarDecl’s anymore.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> 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.</div><div class=""><br class=""></div><div class="">(Perhaps the static analyzer needs more than that in order to produce more user-friendly diagnostics?)</div></div></div></div>

</div></blockquote><div><br class=""></div>We are not even there yet for structured bindings, just trying to make the analyzer understand them.<br class=""><br class=""></div><div><br class=""></div><br class=""></body></html>