<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="">Hi Richard,<div class=""><br class=""></div><div class="">Thanks for your reply.</div><div class="">Rewriting the AST does sound like a reasonable proposition indeed!</div><div class="">We’ll see whether it can be done without compromising user-friendly diagnostics.</div><div class=""><br class=""></div><div class="">George<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2018, at 2:11 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" 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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On 2 April 2018 at 13:52, George Karpenkov via cfe-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;" class="">Hi Richard,<div class=""><br class=""></div><div class="">Thanks for your reply!<br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 30, 2018, at 8:49 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="m_4536569605347199083Apple-interchange-newline"><div class=""><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;" class=""><div class=""><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;" class=""><div class=""><div class=""><div class=""><br class=""><br class=""></div>Right, sure, but I don’t have a convenient way to find that DecompositionDecl from a given BindingDecl,</div><div class="">and sometimes I need to act based on the BindingDecl alone.</div></div></div></blockquote></div></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Can you give an example?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class="">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 class="">chances are it will remain the same.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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: 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;" class=""><div class=""><div class=""><span class=""><blockquote type="cite" class=""><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;" class=""><div dir="auto" class="">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" class=""><br class=""></div><div dir="auto" class="">This was a somewhat controversial decision, but it doesn't look like it's going to be reversed.</div><div dir="auto" class=""><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;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><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;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">That's what the CFG for the above function should represent.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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" class=""><br class=""></div><div dir="auto" class="">IIRC, the CFG expands CXXDefaultArgExprs and CXXDefaultInitExprs; this case is analogous to those.</div></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, you are right; To be honest, I wasn’t previously familiar with that part of the codebase.</div><div class="">Yet still, those are very simple replacements, and IIRC those are the only two.</div><div class=""><br class=""></div><div class="">Supporting structured bindings would be indeed easier if we could have a simpler AST,</div><div class="">could you give an advice on what would be an equivalent AST we should rewrite to?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">You should rewrite a DeclRefExpr denoting a BindingDecl into the binding expression (BindingDecl::getBinding()) of that binding.</div><div class=""> </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;" class=""><div class=""><div class=""><div class="">Would producing a MemberExpr reading from the struct at *use* time be completely semantically equivalent?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes.</div><div class=""> </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;" class=""><div class=""><div class=""><div class="">My previous impression was that for structured bindings load from the struct happens when the binding occurs,</div><div class="">not when the actual read is performed.</div><div class="">[though of course such rewrites would impede producing good diagnostic messages for the user]</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The member access happens each time the binding is named, not up-front.</div><div class=""><br class=""></div><div class="">(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 class=""> </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;" class=""><div class=""><div class=""><span class=""><blockquote type="cite" class=""><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;" class=""><div dir="auto" class=""><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;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><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;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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;" class=""><div class=""><span 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 class=""><br class=""></div></span>We are not even there yet for structured bindings, just trying to make the analyzer understand them.<br class=""><br class=""></div><div class=""><br class=""></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a></blockquote></div></div></div></div></blockquote></div><br class=""></div></div>______________________________<wbr class="">_________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a></blockquote></div></div></div></blockquote></span></div><br class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a></blockquote></div></div></div></div></blockquote></div><br class=""></div></body></html>