
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Aug 5, 2014, at 10:18 , Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 5, 2014 at 7:15 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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?</div>

</div></blockquote><div><br></div><div>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).</div></div></div></div></blockquote><br></div><div>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.</div><div><br></div><div>Jordan</div></body></html>