<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Fri, 30 Mar 2018, 20:22 George Karpenkov via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Richard,<div><br></div><div>Thanks for your reply!<br><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></div></blockquote><div><br></div>Right, sure, but I don’t have a convenient way to find that DecompositionDecl from a given BindingDecl,</div><div>and sometimes I need to act based on the BindingDecl alone.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Can you give an example?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div>Given a statement, the analyzer processes it just based on AST.</div><div>What would “expand” mean here? Defining a kind of intermediate representation the analyzer operates on?</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, see below.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><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></div></div></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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></div></span><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></div></div></blockquote><div><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>Yes, yes, of course I understand that Clang implements the standard correctly.</div><div>I was just saying that the wording of c++17 standard is a bit unfortunate for us,</div><div>since it means a lot of special casing.</div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Simple example:</div><div><br></div><div>struct A { int x, y; };</div><div><br></div><div>void f(A a) {</div><div> auto [v, w] = a;</div><div> use(v, w);</div><div>}</div><div><br></div><div>This gives you a DecompositionDecl, which is a kind of VarDecl, of type A, initialized with 'a'. Let's call that 'e'.</div><div>It also gives you two BindingDecls, which are symbolic names for the expressions 'e.x' and 'e.y'.</div><div>So the evaluation semantics of the above function are as if you wrote:</div><div><br></div><div>void f(A a) {</div><div> A e = a;</div><div> use(e.x, e.y);</div><div>}</div></div></div></div></div></blockquote><div><br></div>Right, thanks for the clarification!</div><div>In my mind, the final version was equivalent to</div><div><br></div><div>void f(A a) {</div><div> auto &v = a.x;</div><div> auto &w = a.y;</div><div> use(v, w);</div><div>}</div><div><br></div><div>but I guess that’s not the case.</div><div>Was a different model chosen in the standard due to performance considerations?</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This was a somewhat controversial decision, but it doesn't look like it's going to be reversed.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>That's what the CFG for the above function should represent.</div></div></div></div></div></blockquote><div><br></div><div>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).</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">IIRC, the CFG expands CXXDefaultArgExprs and CXXDefaultInitExprs; this case is analogous to those.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> 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'.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></div><div>(Perhaps the static analyzer needs more than that in order to produce more user-friendly diagnostics?)</div></div></div></div></div></blockquote><div><br></div></span>We are not even there yet for structured bindings, just trying to make the analyzer understand them.<br><br></div><div><br></div><br></div><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></div></div></div></blockquote></div><br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>