On Mon, Nov 17, 2014 at 8:29 AM, Brad King <[email protected]> wrote:
> On 11/12/2014 08:43 PM, Richard Smith wrote: > > On Fri, Oct 31, 2014 at 6:26 AM, Brad King wrote: > >> once one error has been emitted the failed > >> declaration is marked as invalid and any further error resulting from > >> encountering the invalid declaration should not be emitted. > > > > Yes, that's the goal and the intent. > > Thanks. Ideally any declaration that fails to compile as a result > of encountering another invalid declaration should also be marked > as invalid. That way tools can identify and work with the valid > subset of the translation unit with no false positives. This is > useful for tools that work with code that is in progress in an > editor, for example. Is that also a goal? > 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. I feel that DiagnosticSuppressionScope is still a valid primitive. > FrontendAction::EndSourceFile deletes the output file if the > Diags.hasErrorOccurred() method returns true. Tools that want to > produce output even in the face of errors need a way to prevent that > along with suppressing error diagnostics. DiagnosticSuppressionScope > does both cleanly so long as it surrounds the proper scope in the > tool's source. Perhaps we can add it with a suitable disclaimer in > the documentation comments about non-local errors? 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
