[PATCH] Proposal on how to fix temporary dtors.

Manuel Klimek klimek at google.com
Wed Aug 6 02:57:43 PDT 2014


On Wed, Aug 6, 2014 at 1:31 AM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Aug 5, 2014, at 10:18 , Manuel Klimek <klimek at google.com> wrote:
>
> On Tue, Aug 5, 2014 at 7:15 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>
>> I'm sorry, I don't understand what you mean by non-leaking. Do you mean
>> that if we decide not to run a destructor, we shouldn't leave that trace in
>> the ProgramState? I think it's okay because it will just get postponed to
>> when the destructor is actually run later, right?
>>
>
> I mean that until the lifetime extension is fixed, there are lifetime
> extended temporaries for which we will mark the ProgramState, but never
> clear it, as with the current modeling of lifetime extended temporaries the
> destructors for them look like normal destructors, not like temporary
> destructors (if we correctly run into them at all, which also has some
> bugs).
>
>
> Ah, I see what you mean. Uh...this doesn't make me happy. Data that stays
> in the state like this stays in the state forever, including post-inlining.
> But I guess it only happens when you turn on temporary destructors, and
> we're planning to fix it before we turn that on generally, so okay.
>

I'll continue to beat that horse until it is thoroughly beaten (so I hope
that situation will not stay that way for too long). If necessary, I'll
just chain you to a chair at the next LLVM dev meeting and we'll work
through it :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140806/6717d316/attachment.html>


More information about the cfe-commits mailing list