<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 17, 2014 at 8:29 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">On 11/12/2014 08:43 PM, Richard Smith wrote:<br>
<span class="">> On Fri, Oct 31, 2014 at 6:26 AM, Brad King wrote:<br>
>> 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.<br>
><br>
</span><span class="">> Yes, that's the goal and the intent.<br>
<br>
</span>Thanks.  Ideally any declaration that fails to compile as a result<br>
of encountering another invalid declaration should also be marked<br>
as invalid.  That way tools can identify and work with the valid<br>
subset of the translation unit with no false positives.  This is<br>
useful for tools that work with code that is in progress in an<br>
editor, for example.  Is that also a goal?<br></blockquote><div><br></div><div>Yes, in a restricted sense: if the declaration of an entity is ill-formed, we want to be aware of that fact when analyzing a use of that entity, to avoid any follow-on diagnostics. But this doesn't extend arbitrarily far: if foo is invalid, and the declaration of bar is well-formed but its definition uses foo, we shouldn't mark the declaration of bar as invalid -- we can and should still use information about bar's declaration in later semantic checks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I feel that DiagnosticSuppressionScope is still a valid primitive.<br>
FrontendAction::EndSourceFile deletes the output file if the<br>
Diags.hasErrorOccurred() method returns true.  Tools that want to<br>
produce output even in the face of errors need a way to prevent that<br>
along with suppressing error diagnostics.  DiagnosticSuppressionScope<br>
does both cleanly so long as it surrounds the proper scope in the<br>
tool's source.  Perhaps we can add it with a suitable disclaimer in<br>
the documentation comments about non-local errors?</blockquote><div><br></div><div>I don't think it's reasonable for this to be an RAII primitive, because once you leave the suppression scope you are left with a potentially-invalid AST and no guarantee you'll ever see a diagnostic for future ill-formed code; once you enter this mode, you can't reasonably leave it again. For that, you can just set the SuppressAllDiagnostics flag on the DiagnosticsEngine.</div></div></div></div>