Thanks, r218520
> On Sep 25, 2014, at 5:32 PM, Richard Smith <[email protected]> wrote: > > Sorry for the delay, LGTM, please go ahead and commit. > > On Fri, Sep 19, 2014 at 4:03 PM, Ben Langmuir <[email protected] > <mailto:[email protected]>> wrote: > >> On Sep 16, 2014, at 5:40 PM, Ben Langmuir <[email protected] >> <mailto:[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
