On Sep 16, 2014, at 5:06 PM, Ben Langmuir <[email protected]> wrote:
>> On Sep 16, 2014, at 1:25 PM, John McCall <[email protected]> wrote:
>>
>> On Sep 16, 2014, at 12:54 PM, Richard Smith <[email protected]> wrote:
>>> On Tue, Sep 16, 2014 at 12:47 PM, John McCall <[email protected]> wrote:
>>> On Sep 16, 2014, at 12:11 PM, Richard Smith <[email protected]> wrote:
>>>> On Tue, Sep 16, 2014 at 11:45 AM, John McCall <[email protected]> wrote:
>>>> On Sep 15, 2014, at 9:47 AM, Ben Langmuir <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
