<div dir="ltr">Sorry for the delay, LGTM, please go ahead and commit.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 4:03 PM, Ben Langmuir <span dir="ltr"><<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@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"><br><div><div><div class="h5"><blockquote type="cite"><div>On Sep 16, 2014, at 5:40 PM, Ben Langmuir <<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 16, 2014, at 5:08 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">On Sep 16, 2014, at 5:06 PM, Ben Langmuir <<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@apple.com</a>> wrote:<br><div><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Sep 16, 2014, at 1:25 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">On Sep 16, 2014, at 12:54 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 16, 2014 at 12:47 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>On Sep 16, 2014, at 12:11 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 16, 2014 at 11:45 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Sep 15, 2014, at 9:47 AM, Ben Langmuir <<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@apple.com</a>> wrote:<br>
> Hi John,<br>
><br>
> This patch fixes the assertion failure I talked to you about in Objective C++ codegen. It turned out to have nothing to do with templates.<br>
><br>
> Fix an assertion failure trying to emit a trivial destructor in ObjC++<br>
><br>
> If a base class declares a destructor, we will add the implicit<br>
> destructor for the subclass in<br>
> ActOnFields -> AddImplicitlyDeclaredMembersToClass<br>
><br>
> But in Objective C++, we did not compute whether we have a trivial<br>
> destructor until after that in<br>
> CXXRecordDecl::completeDefinition()<br>
><br>
> This was leading to a mismatch between the class, which thought it had<br>
> no trivial destructor, and the CXXDestructorDecl, which considered<br>
> itself trivial.<br>
<br>
</div>I feel like hasTrivialDestructor should return the right value here. I understand (and am saddened by) the hack about not setting PlainOldData until completeDefinition, but maybe we can set/clear the rest of the bits eagerly?</blockquote><div><br></div><div>Why do we have to delay setting the PlainOldData flag?</div></div></div></div>
</blockquote></div><br></div></div><div>There is a diagnostic which wants to warn about structs that are only POD in non-ARC modes.</div></div></blockquote><div><br></div><div>Thanks, I suspected something along those lines. Perhaps we could track both properties and still perform the calculation eagerly:</div><div><br></div><div>- bool isPOD() const { return data().PlainOldData; }</div><div>+ bool isPOD() const { return data().PlainOldData && !data().HasARCObjectMember; }<br></div><div>+ bool wouldHaveBeenPODIfItWerentForYouMeddlingKids() const { return data().PlainOldData; }</div></div></div></div>
</blockquote></div><br><div>That works for me, or we could even give it its own bit in the definition data; it’s not like we aren’t tracking a number of other things there for similar purposes.</div><div><br></div><div>John.</div></div></div></blockquote><br></div><div>John and I took a look and it turns out we killed the warning in question as part of removing -Warc-abi. I’ve attached an updated patch that just eagerly sets these bits in addedMember so we will get the correct value inside AddImplicitlyDeclaredMembersToClass.</div></div></blockquote><div><br></div></div>Looks great to me; thanks, Ben.<div><br></div><div>John.</div></div></div></blockquote><br></div><div>Thanks John.</div><div><br></div><div>Richard, did you have any other feedback, or shall I commit?</div></div></div></blockquote><div><br></div></div></div><div>ping</div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>Ben</div></div></div></blockquote></div><br></div></blockquote></div><br></div>