> On Sep 16, 2014, at 5:40 PM, Ben Langmuir <[email protected]> wrote: > > >> On Sep 16, 2014, at 5:08 PM, John McCall <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sep 16, 2014, at 5:06 PM, Ben Langmuir <[email protected] >> <mailto:[email protected]>> wrote: >>>> On Sep 16, 2014, at 1:25 PM, John McCall <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On Sep 16, 2014, at 12:54 PM, Richard Smith <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> On Tue, Sep 16, 2014 at 12:47 PM, John McCall <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> On Sep 16, 2014, at 12:11 PM, Richard Smith <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> On Tue, Sep 16, 2014 at 11:45 AM, John McCall <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> On Sep 15, 2014, at 9:47 AM, Ben Langmuir <[email protected] >>>>>> <mailto:[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. > > Thanks John. > > Richard, did you have any other feedback, or shall I commit?
ping > > Ben
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
