[PATCH] Fix an assertion failure trying to emit a trivial destructor in ObjC++

[Ben Langmuir]

Thanks, r218520


> On Sep 25, 2014, at 5:32 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> 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 <mailto:blangmuir at apple.com>> wrote:
> 
>> On Sep 16, 2014, at 5:40 PM, Ben Langmuir <blangmuir at apple.com <mailto:blangmuir at apple.com>> wrote:
>> 
>> 
>>> On Sep 16, 2014, at 5:08 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>> 
>>> On Sep 16, 2014, at 5:06 PM, Ben Langmuir <blangmuir at apple.com <mailto:blangmuir at apple.com>> wrote:
>>>>> On Sep 16, 2014, at 1:25 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>>>> 
>>>>> On Sep 16, 2014, at 12:54 PM, Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>>>>>> On Tue, Sep 16, 2014 at 12:47 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>>>>> On Sep 16, 2014, at 12:11 PM, Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>>>>>>> On Tue, Sep 16, 2014 at 11:45 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>>>>>> On Sep 15, 2014, at 9:47 AM, Ben Langmuir <blangmuir at apple.com <mailto: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/20140926/7732d193/attachment.html>