Partial fix #11892 (Safety: status message when checkers are skipped)

[danmar]

Work in progress to be more visible when there are critical errors, and no checking is executed in a file.

[firewave]

What about introducing a fatal severity instead?

Should also include missingInclude as incomplete code will also lead to incomplete analysis.

[danmar]

I do not agree about adding missingInclude. We will always have false negatives. Our parser is far from perfect. I will never promise that we have "complete" analysis.

I would normally include all local headers when I check some code.

More include paths are not always better. It can have a significant performance penalty. System headers should not be included in general. And I have the feeling that if the header code is very complex it can be better to leave it out.

[danmar]

For the error ids I listed, the analysis is stopped. The checkers are not executed at all.

[danmar]

About adding a fatal severity. In theory it sounds good to me. It's just that it's one more thing that will break plugins and scripts.

[firewave]

Just off the top of my head (it's based on something I considered for another improvement).

• add Severity::fatal and change the errors in question
• add Settings::fatalErrors (default: false)
• and command-line option --fatal-errors
• add support for fatal to --enable/--disable
• if that option is not set treat them simply as error
• always enable that option for the GUI analysis

This way you can opt-in/opt-out and it fits in the existing frameworks.

[firewave]

This should be configurable as it will most certainly break existing installations which have suppressed these errors (for a long time possibly).

[danmar]

This should be configurable as it will most certainly break existing installations which have suppressed these errors

I believe that if such errors are suppressed then my changes will not change the behavior of cppcheck.

[danmar]

@firewave After your questions I am not sure if this is the right approach. At least not in the command line. Thanks!

[danmar]

hmm.. but I guess the GUI changes makes sense at least to start with..

[danmar]

@firewave maybe it would make sense to treat missingInclude, varid0, checkLibrary, debug warnings, etc differently if the check level is "exhaustive"?

[firewave]

@firewave maybe it would make sense to treat missingInclude, varid0, checkLibrary, debug warnings, etc differently if the check level is "exhaustive"?

We can only include missingInclude without additional logic. Everything else needs additional logic or features otherwise you will be drowning in false positives you will not be able to fix. I will try to file tickets about this in the next days. It also involves adding some new data collection and reports to daca first. (If I were in a better condition, all of that would have been implemented already - probably...but I guess I am a bit overly optimistic 🫤)

I thought about the same. Making fatal errors non-fotal with exhaustive. But that seems a bit too obscure. Using the existing framework would be better.