Adding local scope and automatic object destructors

-cfe-commits, +cfe-dev (sorry, /me unable to handle mailing lists)

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. 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.)

Jordan

-cfe-commits, +cfe-dev (sorry, /me unable to handle mailing lists)

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

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.