[PATCH] Proposal on how to fix temporary dtors.

Manuel Klimek klimek at google.com
Mon Jul 28 09:37:03 PDT 2014


Btw, I'm still trying to figure out from looking at CodeGen how all this is
supposed to work.


On Mon, Jul 28, 2014 at 6:36 PM, Manuel Klimek <klimek at google.com> wrote:

> 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/2ecc6de7/attachment.html>


More information about the cfe-commits mailing list