[PATCH] Fix an assertion failure trying to emit a trivial destructor in ObjC++
Richard Smith
richard at metafoo.co.uk
Thu Sep 25 17:32:10 PDT 2014
Sorry for the delay, LGTM, please go ahead and commit.
On Fri, Sep 19, 2014 at 4:03 PM, Ben Langmuir <blangmuir at apple.com> wrote:
>
> On Sep 16, 2014, at 5:40 PM, Ben Langmuir <blangmuir at apple.com> wrote:
>
>
> On Sep 16, 2014, at 5:08 PM, John McCall <rjmccall at apple.com> wrote:
>
> On Sep 16, 2014, at 5:06 PM, Ben Langmuir <blangmuir at apple.com> wrote:
>
> On Sep 16, 2014, at 1:25 PM, John McCall <rjmccall at apple.com> wrote:
>
> On Sep 16, 2014, at 12:54 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Tue, Sep 16, 2014 at 12:47 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Sep 16, 2014, at 12:11 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>> On Tue, Sep 16, 2014 at 11:45 AM, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Sep 15, 2014, at 9:47 AM, Ben Langmuir <blangmuir at apple.com> wrote:
>>> > Hi John,
>>> >
>>> > 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.
>>> >
>>> > Fix an assertion failure trying to emit a trivial destructor in
>>> ObjC++
>>> >
>>> > If a base class declares a destructor, we will add the implicit
>>> > destructor for the subclass in
>>> > ActOnFields -> AddImplicitlyDeclaredMembersToClass
>>> >
>>> > But in Objective C++, we did not compute whether we have a trivial
>>> > destructor until after that in
>>> > CXXRecordDecl::completeDefinition()
>>> >
>>> > This was leading to a mismatch between the class, which thought it
>>> had
>>> > no trivial destructor, and the CXXDestructorDecl, which considered
>>> > itself trivial.
>>>
>>> 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?
>>
>>
>> Why do we have to delay setting the PlainOldData flag?
>>
>>
>> There is a diagnostic which wants to warn about structs that are only POD
>> in non-ARC modes.
>>
>
> Thanks, I suspected something along those lines. Perhaps we could track
> both properties and still perform the calculation eagerly:
>
> - bool isPOD() const { return data().PlainOldData; }
> + bool isPOD() const { return data().PlainOldData &&
> !data().HasARCObjectMember; }
> + bool wouldHaveBeenPODIfItWerentForYouMeddlingKids() const { return
> data().PlainOldData; }
>
>
> 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.
>
> John.
>
>
> 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.
>
>
> Looks great to me; thanks, Ben.
>
> John.
>
>
> Thanks John.
>
> Richard, did you have any other feedback, or shall I commit?
>
>
> ping
>
>
> Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140925/97f9beac/attachment.html>
More information about the cfe-commits
mailing list