<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks for the help!<br>
<br>
I don't think i'll be able to help with the proposed refactoring on
the AST side, but i'll be happy to update the analyzer when
CXXBindTemporaryExpr is removed. This sounds like something we could
totally work with, and it'd be much cleaner than what we currently
have.<br>
<br>
<div class="moz-cite-prefix">On 3/29/18 9:54 PM, John McCall via
cfe-dev wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:03C1AA32-6E90-4FA2-8BB6-2E412335542E@apple.com">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 29, 2018, at 7:31 PM, Richard Smith <<a
href="mailto:richard@metafoo.co.uk" class=""
moz-do-not-send="true">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="" moz-do-not-send="true">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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>