<div dir="ltr">I think the right fix for PR18284 is to mark just the method invalid.  The problem of invalid base classes still needs to be solved, though.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 9:38 AM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I've been looking at PR18284, where we have two RecordDecls, one the subclass of the other, and we go and mark the superclass RecordDecl as invalid, while keeping the subclass valid. This ends up confusing the code that computes the subclass's layout, since that only checks if the subclass is valid and then asserts that all superclasses are valid.</div>

<div><br>Is the bug that they layout code assumes that "record valid => superclass records valid", or is the bug that the code that marks the superclass as invalid doesn't mark all subclasses invalid too?</div>

<div><br></div><div>Likewise, should a class being valid imply that all its methods and fields are valid? One possible fix for PR18284 is to stop marking a class invalid when one of its methods is invalid (this is currently done in some cases, but not in all), but that doesn't seem like the right fix.</div>

<div><br></div><div>Thanks,</div><div>Nico</div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>