Sorry for the delay, LGTM, please go ahead and commit. On Fri, Sep 19, 2014 at 4:03 PM, Ben Langmuir <[email protected]> wrote:
> > 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]> wrote: > > 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. > > > 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
