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

Tue, 16 Sep 2014 17:12:07 -0700


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.

Ben

Attachment: rdar18249673.2.patch
Description: Binary data



_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to