[patch] Don't let invalid methods mark their RecordDecl invalid

Nico Weber thakis at chromium.org
Fri Dec 20 16:27:44 PST 2013


On Fri, Dec 20, 2013 at 4:18 PM, John McCall <rjmccall at apple.com> wrote:

> On Dec 20, 2013, at 4:06 PM, Reid Kleckner <rnk at google.com> wrote:
>
> +John, since it was his code.
>
>
> Are there other ways we can get an invalid record decl and then do layout
> on a derived class to trigger PR18284?  If so, it seems like this doesn't
> fix the underlying issue.
>
>
> A class should definitely be invalid if any of its base classes is
> invalid.  Making it invalid when one of its members is invalid is probably
> for the best; I would guess that that’s now occurring through some other
> channel, causing the original test to successfully not crash.
>

As far as I can tell, classes aren't always marked invalid if they have
invalid methods at the moment. One example from PR18284 where RunTest is an
invalid method but both B and A are valid:

  class A {};
  class C : public A {};
  void A::RunTest() {}

It seems like whatever caused the crash that's fixed by r110891 is now also
fixed in some other way.

This is the example where clang currently marks A as invalid but keeps C
valid:

  class A {};
  class C : public A {};
  A::RunTest() {}


> I’m not sure what about the linked patch is making a base class invalid
> when a method in a derived class is invalidated, though?
>

No, the patch changes things to not mark a class invalid if one of its
methods is invalid. This was the only place I could find where a class was
marked invalid after its definition is complete. (Hence with this patch,
C's superclass A will be valid too, only its method stays invalid, like
with the first snippet).


>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131220/7648e4ef/attachment.html>


More information about the cfe-commits mailing list