Hello,
We’ve run into a problem using libclang for cpp support in KDevelop: once an #included file is not found, a fatal error is generated which disables all further diagnostics.
In the context of KDevelop, it is quite important that this be downgraded to a non-fatal error so that further missing includes and issues can be marked in the IDE. It’s further desirable that the IDE support is still helpful in the absence of a missing but unimportant #include.
I’ve found no way to do this with compiler flags; err_pp_file_not_found has no category so -Wno-fatal-errors=foo can’t help (not clear if that’s the correct method even if there was a category).
Is there a way to do this that I missed seeing? Can this diagnostic be re-mapped from fatal to error?
If there’s no existing way to do this, could some interface or compiler flag be added so that err_pp_file_not_found_not_fatal is used instead? What would be the correct place/way to configure this?
Thanks,
-Olivier JG
This is important to us for the same reasons. In our case we only care about reporting additional file-not-found errors. The others usually become too noisy. I haven’t found any existing option to control this. We have a local patch to continue reporting file-not-found errors after a fatal error (may be slightly out of date):
--- a/lib/Basic/DiagnosticIDs.cpp
+++ b/lib/Basic/DiagnosticIDs.cpp
@@ -618,7 +618,7 @@ bool DiagnosticIDs::ProcessDiag(DiagnosticsEngine &Diag) const {
// If a fatal error has already been emitted, silence all subsequent
// diagnostics.
- if (Diag.FatalErrorOccurred) {
+ if (Diag.FatalErrorOccurred && DiagID != diag::err_pp_file_not_found) {
if (DiagLevel >= DiagnosticIDs::Error &&
Diag.Client->IncludeInDiagnosticCounts()) {
++Diag.NumErrors;
I would love to see an option to control this behavior added to the mainline. Are there already other flags meant specifically for IDE integration? Maybe this could piggyback on one of them or do something similar?
Jason
This is important to us for the same reasons. In our case we only care
about reporting additional file-not-found errors.
Olivier, is this also the case for you, or do you want to see other
diagnostics after a missing #include?
The others usually become too noisy. I haven’t found any existing option
to control this. We have a local patch to continue reporting file-not-found
errors after a fatal error (may be slightly out of date):
--- a/lib/Basic/DiagnosticIDs.cpp
+++ b/lib/Basic/DiagnosticIDs.cpp
@@ -618,7 +618,7 @@ bool DiagnosticIDs::ProcessDiag(DiagnosticsEngine
&Diag) const {
// If a fatal error has already been emitted, silence all subsequent
// diagnostics.
- if (Diag.FatalErrorOccurred) {
+ if (Diag.FatalErrorOccurred && DiagID != diag::err_pp_file_not_found) {
if (DiagLevel >= DiagnosticIDs::Error &&
Diag.Client->IncludeInDiagnosticCounts()) {
++Diag.NumErrors;
I would love to see an option to control this behavior added to the
mainline.
I don't think we need an option for this; it seems reasonable to always
report missing #includes, even if we've already hit a fatal error, because
a missing include is very unlikely to be caused by a prior missing include
(they may have a common cause, but that's OK).
Are there already other flags meant specifically for IDE integration? Maybe
Only reporting additional file-not-found errors should be good enough for
us as well.
-Olivier JG
I have encountered the same issue, but my use case is probably a little different. I’m using clang in an interactive setting, where users frequently mistype their #include’s. However, I see there already is a SuppressIncludeNotFoundError, in the Preprocessor, which is basically what I need (though I would still prefer to get the diagnostic that the file wasn’t found as an error).
I wonder if it should continue to report all fatal errors instead of just file-not-found. Also, my patch sort of circumvents the 20 error fatal cutoff. Maybe that’s okay.
Jason
I wonder if it should continue to report all fatal errors instead of just
file-not-found.
I think it makes sense to report file-not-found repeatedly, because
recovery from previous errors is very unlikely to be the cause of later
file-not-found errors. For the other fatal cases, that is not the case, so
I don't think it makes as much sense to suppress them.
Also, my patch sort of circumvents the 20 error fatal cutoff. Maybe that’s
okay.
That seems problematic; if essentially-correct code #includes a bunch of
headers, but the build fails due to a missing -I path, it seems especially
important to respect the error limit.
I would prefer that we add a flag to diagnostics to indicate if they should
be shown even after a fatal error, and then mark err_pp_file_not_found with
that flag in the .td file, rather than hard-coding that particular
diagnostic.
I wonder if it should continue to report all fatal errors instead of just
file-not-found.
I think it makes sense to report file-not-found repeatedly, because
recovery from previous errors is very unlikely to be the cause of later
file-not-found errors. For the other fatal cases, that is not the case, so
I don't think it makes as much sense to suppress them.
Umm, ... to *not* suppress them =)
Okay, I agree. I’ll submit a patch along those lines.