<div dir="ltr">This is getting more and more interesting:<div>When using conditional operators, the destructor called at the end of the lifetime extension depends on the truth value of the condition (at least that is how it looks in the AST, and that's iiuc how codegen handles it).</div>
<div><br></div><div>This seems to be another indication that we'll want to reuse the machinery for CFGTemporaryDtor to handle the switch on which dtor to run in the end. No idea yet how I'll get the correct block in there.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 30, 2014 at 10:39 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Wed, Jul 30, 2014 at 4:50 AM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</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"><div><div><br><div><div>On Jul 29, 2014, at 8:13 , Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">-cfe-commits, +cfe-dev (sorry, /me unable to handle mailing lists)</div><div class="gmail_quote"><br></div><div class="gmail_quote">
On Tue, Jul 29, 2014 at 3:51 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jordan,<div><br></div><div>I am working on a fix for lifetime extended temporaries, and I have a hard time understanding some of the code.</div>
<div>1. addLocalScopeForVarDecl already has a FIXME; I have no idea how to apply that though - it seems like we always add the VarDecl to the scope, even if the type we look at is from the lifetime extended temporary; as noted, we need to be able to handle the scope of multiple lifetime extended temporaries; do we need a completely different approach here then?</div>
<div>2. addAutomaticObjDtors seems to work on what addLocalScopeForVarDecl does, so it seems like we'll need to adapt this after solving (1)</div><div><br></div><div>My main problem is that I don't have enough insight into what else the local scope is used for, so I'm not sure how we'd want to change it to account for lifetime extended temporaries.</div>
</div></blockquote><div><br></div><div>After some investigation, it looks to me like we'll want to add some way to CFGAutomaticObjDtor to allow not only specifying VarDecls, but somehow directly referencing the lifetime extended expressions (?)</div>
</div></div></div></blockquote><br></div></div></div><div>Hm. That's interesting, because we'd really like to clean up those expressions, but if we had to keep them alive I guess we could. For the AggregateRef test case in <a href="http://reviews.llvm.org/D4696" target="_blank">http://reviews.llvm.org/D4696</a>, we'd be able to recover all information from the VarDecl: this member came from this expression, which was a temporary, so destroy that.</div>
</div></blockquote><div><br></div></div><div>But to do that we'd need to dig arbitrarily deep into the objects of the variable. It seems to me like it'd be much clearer code-wise that the temporary dtor is still a temporary dtor when it's lifetime extended - it's just executed at a later point. At least that matches my mental model better.</div>
<div class="">
<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"><div> Likewise for the subobject test I just suggested: go up to the base region, which was a temporary, so destroy it. <i>Combining</i> those seems a bit iffy, but not impossible.</div>
<div><br></div><div>I'm not sure we'd need to stick strictly to the existing destructor CFG elements either. Let's come up with a model that works, and then figure out which CFG elements we need for it. (For example, what I just said above is easy enough in the analyzer if you just did all that work at the CFGAutomaticObjDtor, but a bit harder to model in the CFG.)</div>
</div></blockquote><div><br></div></div><div>I think the model that temporaries are destroyed by CFGTemporaryDtor, either at the end of the full statment, or, when lifetime extended, at then end of the lifetime extension, makes a lot of sense. Any concerns why you think this is the wrong model?</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>
</blockquote></div><br></div>