Export the actual enabled checks in reports

[elupus]

Is your feature request related to a problem? Please describe.

When auditing a release where codechecker has been used. It would be very good to know, per-file which checks where enabled. This becomes even more hard to do when .clang-tidy per file configuration files are used.

Describe the solution you would like

Store a per-file enabled check information in the reports. For clang-tidy dump-config could be used to output the resulting enabled checks.

Describe alternatives you have considered

Not found any good options. If codechecker was not used, we could possible script clang-tidy to do a dump-config call per file and store that in parallel to a per-file report.

Additional context

[bruntib]

This PR could be a solution to this ticket: #4468.

CodeChecker cmd runs -o json

This command prints the enabled checkers for the runs.

Listing enabled checkers per file is not possible, because it may occur that in one analysis a checker was enabled for that file and in another analysis it wasn't.

I would close this ticket, but feel free to comment if further help is needed. Thank you!

[elupus]

Well you can have suppressed rules per file:
https://github.com/Ericsson/codechecker/blob/master/docs/analyzer/user_guide.md#setting-with-config-file

These are very important in a report.

[elupus]

And as mentioned cling tidy local rules. All these are very important to know.

[bruntib]

A checker being enabled, or a report is suppressed are two different things. Suppression belongs to a report, and enabled/disabled status belongs to a checker. Even if a report is suppressed, the checker is enabled that finds it.
Also, it is possible that only one occurrence is suppressed:

int main()
{
  // codechecker_suppress [cure.DivideZero] This report is suppressed.
  int i = 1 / 0;

  // This is not suppressed.
  int i = 2 / 0;
}

[elupus]

Right true, for suppression that make sense. For clang tidy rules in a subdirectory not so much. But maybe that is considered put of scope?

[bruntib]

This behavior is intentional. But maybe I misunderstand your point. What is the problem exactly, that you'd like to solve?

[elupus]

On delivery of a product, include a report of all enabled and disabled checks. If a check is disabled in a tidy config in a subdirectory, that should not be seen as just no issues of that thpe existing, it should be in the report that the checks for that file was disabled.