[cfe-dev] Downgrading/mapping fatal errors to errors (#include not found)

[Richard Smith]

On Mon, Jan 5, 2015 at 8:30 AM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Sun, Jan 4, 2015 at 8:15 PM, Jason Haslam <jason.haslam at gmail.com>
> wrote:
>
>> 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 =)


> 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.
>
>
>> Jason
>>
>>
>> On Jan 4, 2015, at 2:19 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>>
>> On Sat, Jan 3, 2015 at 11:15 PM, Jason Haslam <jason.haslam at gmail.com>
>> wrote:
>>
>>> 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 this could piggyback on one of them or do something similar?
>>>
>>> Jason
>>>
>>>
>>> > On Dec 31, 2014, at 4:13 AM, Olivier J. G. <olivier.jg at gmail.com>
>>> wrote:
>>> >
>>> > 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
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150105/244c3caf/attachment.html>