<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 31, 2014 at 6:26 AM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/30/2014 09:06 PM, Richard Smith wrote:<br>
>> One can see that both B::B() and C::C() get errors as desired.<br>
><br>
> That is not guaranteed, and will no longer be the case when we<br>
> fix the bug described above.<br>
<br>
</span>Interesting.  Please help me understand this: the docs of setInvalidDecl<br>
say it is for "graceful error recovery".  From the point of view of a<br>
compiler that sounds like once one error has been emitted the failed<br>
declaration is marked as invalid and any further error resulting from<br>
encountering the invalid declaration should not be emitted.  That way<br>
users do not see errors that are only caused by earlier errors.  Is that<br>
the goal?</blockquote><div><br></div><div>Yes, that's the goal and the intent.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In that case the current behavior does appear to be a bug.</blockquote><div><br></div><div>I think so. There seem to be a few bugs here: we shouldn't mark an instantiated function as invalid because instantiating the body failed (there's nothing wrong with the declaration); we should use a different mechanism to track that we shouldn't try to instantiate it again. And we shouldn't give overload resolution errors if our candidate set contained an invalid declaration.</div></div></div></div>