<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 April 2018 at 13:52, George Karpenkov via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><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><span class=""><br><blockquote type="cite"><div>On Mar 30, 2018, at 8:49 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br class="m_4536569605347199083Apple-interchange-newline"><div><div dir="auto" 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><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><div><div><br><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></div></blockquote><div><br></div></span><div>Let’s say a structured binding is written into, and then some function is called, and then we read from that binding again.</div><div>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,</div><div>chances are it will remain the same.</div></div></div></div></blockquote><div><br></div><div>I think that will just work if you expand references to BindingDecls into their binding expressions: both before and after, you'll end up evaluating an lvalue denoting the same subobject of the DecompositionDecl.</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"><div><div><span class=""><blockquote type="cite"><div dir="auto" 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 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: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><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></blockquote><div><br></div></span><div>Yes, you are right; To be honest, I wasn’t previously familiar with that part of the codebase.</div><div>Yet still, those are very simple replacements, and IIRC those are the only two.</div><div><br></div><div>Supporting structured bindings would be indeed easier if we could have a simpler AST,</div><div>could you give an advice on what would be an equivalent AST we should rewrite to?</div></div></div></div></blockquote><div><br></div><div>You should rewrite a DeclRefExpr denoting a BindingDecl into the binding expression (BindingDecl::getBinding()) of that binding.</div><div> </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"><div><div><div>Would producing a MemberExpr reading from the struct at *use* time be completely semantically equivalent?</div></div></div></div></blockquote><div><br></div><div>Yes.</div><div> </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"><div><div><div>My previous impression was that for structured bindings load from the struct happens when the binding occurs,</div><div>not when the actual read is performed.</div><div>[though of course such rewrites would impede producing good diagnostic messages for the user]</div></div></div></div></blockquote><div><br></div><div>The member access happens each time the binding is named, not up-front.</div><div><br></div><div>(However, for a tuple-like class type -- eg, std::tuple<...> or std::pair<...> -- the binding declarations have expressions that denote auxiliary variables (BindingDecl::getHoldingVar()) which are initialized up-front. In order to correctly handle those cases, when you build the CFG for a DecompositionDecl, you'll need to walk its bindings, check for holding variables, and also build CFG for those variables. You can search for "getHoldingVar()" through the clang codebase to see the other places this is already done -- in CodeGen and the constant expression evaluator.)</div><div> </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"><div><div><span class=""><blockquote type="cite"><div dir="auto" 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 dir="auto"><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><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>______________________________<wbr>_________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">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/<wbr>mailman/listinfo/cfe-dev</a></blockquote></div></div></div></div></blockquote></div><br></div></div>______________________________<wbr>_________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">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/<wbr>mailman/listinfo/cfe-dev</a></blockquote></div></div></div></blockquote></span></div><br></div></div><br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>