[cfe-dev] Adding local scope and automatic object destructors

[Manuel Klimek]

This is getting more and more interesting:
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).

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.



On Wed, Jul 30, 2014 at 10:39 AM, Manuel Klimek <klimek at google.com> wrote:

> On Wed, Jul 30, 2014 at 4:50 AM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>
>>
>> On Jul 29, 2014, at 8:13 , Manuel Klimek <klimek at google.com> wrote:
>>
>> -cfe-commits, +cfe-dev (sorry, /me unable to handle mailing lists)
>>
>> On Tue, Jul 29, 2014 at 3:51 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> Hi Jordan,
>>>
>>> I am working on a fix for lifetime extended temporaries, and I have a
>>> hard time understanding some of the code.
>>> 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?
>>> 2. addAutomaticObjDtors seems to work on what addLocalScopeForVarDecl
>>> does, so it seems like we'll need to adapt this after solving (1)
>>>
>>> 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.
>>>
>>
>> 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 (?)
>>
>>
>> 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 http://reviews.llvm.org/D4696, we'd be able to
>> recover all information from the VarDecl: this member came from this
>> expression, which was a temporary, so destroy that.
>>
>
> 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.
>
>
>> Likewise for the subobject test I just suggested: go up to the base
>> region, which was a temporary, so destroy it. *Combining* those seems a
>> bit iffy, but not impossible.
>>
>> 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.)
>>
>
> 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?
>
> Cheers,
> /Manuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140730/2b202773/attachment.html>