<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 4/2/18 2:11 PM, Richard Smith via
cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOfiQqk5rkAjNsuWigSHhXqf9v8fD8Ux1uoyebM55+o2XfgVwA@mail.gmail.com">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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>
</span></div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
Thank you for the explanation! I was also very confused.<br>
<br>
We do expand CXXDefaultInitExprs for sema warnings CFG, but not for
the CFG analyzer. We don't expand CXXDefaultArgExprs yet.<br>
<br>
I have a concern, which is probably invalid, about expanding
expressions that can appear more than once. So far in a lot of
places (in the analyzer in particular) we've been relying on every
expression appearing only once within a single CFG, which would no
longer be the case if we expand CXXDefaultArgExprs or
DeclRefExprs-to-BindingDecls.<br>
<br>
In particular, in the analyzer it's common to keep track of "the
value of the expression". We are unable to handle the situation when
the same expression, within the same call stack frame, in the same
moment of time, has two different values. For BindingDecl this
shouldn't be a problem because its expression will always have the
same value. For CXXDefaultArgExpr it seems to also not be a problem
because it is always surrounded by its respective function call,
which is already the next moment of time - and we won't expand the
same CXXDefaultArgExpr twice in the same call. Even if
CXXDefaultArgExpr calls itself recursively, we're not on the same
stack frame anymore. Am i understanding correctly that we're not
ever going to be required to maintain two different values for
CXXDefaultArgExpr sub-expressions or for binding sub expressions? Is
there something that protects us from such situations, apart from
"that's where we are at the moment"?<br>
<br>
The other problem i'm immediately seeing in the analyzer is to
prevent it from thinking that we've found an infinite loop when we
visit the same expression twice without any change in the state of
the program (which is a known but presumably relatively harmless bug
in our current CXXDefaultArgExpr handling). But that should be
relatively easy to resolve.<br>
<br>
There is also a certain amount of "unknown unknowns" here, because
i've no idea in how many other places we rely upon, or will need to
rely upon every expression appearing only once.<br>
<br>
The alternative i've been considering for now was to provide "fake
stack frames" for evaluating such expandable expressions instead of
expanding them directly into the CFG. This would be an analyzer-side
fix, but it may be fine if other users of the CFG are fine with
expanding.<br>
<br>
It might be also possible to deep-copy the expressions when
expanding. But in case of CXXDefaultArgExpr it would assume
deep-copying arbitrary expressions, which sounds hard.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAOfiQqk5rkAjNsuWigSHhXqf9v8fD8Ux1uoyebM55+o2XfgVwA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<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><span class="">
<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"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</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>