<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></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 7:31 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 14:42, John McCall 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Mar 29, 2018, at 5:32 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="gmail-m_-4508392518494747990Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 29 March 2018 at 14:19, John McCall 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2018, at 5:10 PM, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-4508392518494747990m_2354426469617881146Apple-interchange-newline"><div class=""><div dir="ltr" class="">Looks like a bug to me, probably template instantiation for the initializer is stripping this node out and we're failing to recreate it when redoing the initialization in the instantiation.<div class=""><br class=""></div><div class="">But I wonder whether we should just ditch the CXXBindTemporaryExpr node entirely. The purpose of marking where a temporary is created that needs a cleanup is handled much better by looking for CXXMaterializeTemporaryExprs (since they also track whether the temporary was lifetime-extended), and it doesn't seem like an imposition to ask clients to work out for themselves whether the type of the temporary needs destruction.</div><div class=""><br class=""></div><div class="">This would require us to start creating CXXMaterializeTemporaryExprs in C++98 for cases like "A().n", where we currently avoid doing so because the language rules say that expression is an rvalue, which in turn means (carefully) extending the C++11 xvalue rules to C++98 mode. But that seems feasible -- the hardest part is likely going to be avoiding using the term "xvalue" in C++98 diagnostics :)<br class=""></div></div></div></blockquote><div class=""><br class=""></div></span>If we're going to do this, I think it would make sense to just store a "semantic value kind" that papers over as many of these language differences as possible, with the understanding that queries about the formal value kind have to be parameterized by LangOpts. So it would have options like:</div><div class=""> - complete pr-value</div><div class=""> - pr-value subobject</div><div class=""> - l-value</div><div class=""> - x-value</div><div class=""> - function reference (because C considers these r-values)</div><div class=""><br class=""></div><div class="">Obviously, some differences (like compound literals) are real semantic differences between languages, but most of the rest of these are extremely artificial and clients ought to be able to ignore them.</div></div></blockquote><div class=""><br class=""></div><div class="">Oh great, now we have a "naming things" problem too ;-)</div></div></div></div></div></blockquote><div class=""><br class=""></div></span>Heh, yeah, I was writing that and questioning everything I put down. :)</div><div class=""><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Yes, I agree, that makes a lot of sense.</div><div class=""><br class=""></div><div class="">If we're going to take on this work, I think we should also consider what should become of ExprClassification.cpp versus the value kind + object kind bits on Expr. It doesn't make much sense to have two independent mechanisms computing largely the same information.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I agree that we might be able to get rid of ExprClassification.</div><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Also, do we need the ObjC parameter / subscript ObjectKind given that we have PseudoObject placeholder types to identify the relevant expressions?</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, that's true, I think we no longer need a special object kind for these.</div><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">(Conversely, compatibility with modern GCC suggests we should have an "underaligned field" object kind, reference bindings to which implicitly create temporaries just like for bit-fields.)</div></div></div></div></div></blockquote><div class=""><br class=""></div></span>Hmm, I feel like this might be more a special-case semantic rule for reference-binding than an actual difference in the expression.</div></div></blockquote><div class=""><br class=""></div><div class="">As far as I can tell, it propagates through expressions exactly like bit-field-ness, and generally acts like the expression is half-way to being a bit-field (<a href="https://godbolt.org/g/teWxN7" class="">https://godbolt.org/g/teWxN7</a>), affecting reference binding but not preventing taking the address.</div></div></div></div></div></blockquote><div><br class=""></div></div>That's fair.<div class=""><br class=""></div><div class="">John.</div></body></html>