[PATCH] Proposal on how to fix temporary dtors.

[Manuel Klimek]

On Mon, Jul 28, 2014 at 6:27 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Jul 28, 2014, at 7:56 , Manuel Klimek <klimek at google.com> wrote:
>
> On Mon, Jul 28, 2014 at 4:01 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Mon, Jul 28, 2014 at 3:43 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> Some more context:
>>> It seems like we already need to do that when building the CFG: for the
>>> lifetime extended object we must not emit the destructor at the end of the
>>> full expression, which we currently do.
>>>
>>
>> And it looks like we're already trying to do that by handing
>> BindToTemporary down. I'm investigating some more...
>>
>
> Found bug, separate patch sent (although right now I think it's also still
> wrong).
> I think we need to fix how we handle lifetime extended temporaries before
> we can really do anything here - the main bug in lifetime extended
> temporary handling is in connecting the MaterializeTemporaryExpr to the
> right CXXBindTemporaryExpr (if it exists). Once that problem is solved, we
> can simple mark the CXXBindTemporary that is lifetime extended once we hit
> the MaterializeTempraryExpr in the static analyzer.
>
>
> I'd really like the CFG to be correct, not something that we have to
> reconstruct correctness for in the analyzer.
>

Yes, but it's currently not correct.


> We should be able to statically tell which temporary a
> MaterializeTemporaryExpr is going to bind to, right? Or rather, we should
> be able to tell whether or not a given CXXBindTemporaryExpr will be
> destroyed or bound if it is executed.
>

Yes, fully agreed, but first we have to fix how to handle lifetime extended
temporaries - the fix *is* getting that information correctly out of the
AST.
I'd rather not mix this patch with a fix for lifetime extended temporaries,
and I'm not sure continuing to maintain this patch until after I fixed
lifetime extended temps is a good idea.


>
> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140728/49f3aab5/attachment.html>