Support for Statistical Checkers

[dkrupp]

Statistical checkers require 2-phase analysis. In the 1st, statistics collection-phase, the source code is analyzed and information is collected about the API usages. These statistics are stored into collection directory. In the 2nd, analysis phase, the collected information is used to find bugs in the code (API usages that are non-conform to the applied coding style).

CodeChecker will support this 2-phase analysis.
Checkers that benefit from the support are api.SpecialReturnValue, api.UncheckedReturnValue.

Add --statistics-collect option to analyze which switches on experimental statistics collection checkers:

• statisticsCollector.ReturnValueCheck
• statisticsCollector.SpecialReturnValue

The option will only be shown if the checkers are available.

The statistics will be stored into in <REPORT-DIR>/statistics directory.

If any of the

• api.SpecialReturnValue
• api.UncheckedReturnValue

checkers are switched on, look for statistics file in the <REPORT-DIR>/statistics directory.

Introduce a new optional analyze argument --preanalize-dir <PREANALYZE-DIR> which is a <REPORT_DIR> with the CTU and statistics pre-analysis results.

Using this parameter it will be possible to share the pre-analysis results between multiple analysis runs. So if this parameter is given, the --ctu-analyze and the ctu-on-the-fly, and the statistical checkers will search for the CTU and statistics interim files in <PRE-ANALYZE-DIR>/ctu and <PRE-ANALYZE-DIR>/statistics directories.

[dkrupp]

Are these options OK like this? What do you think?

[whisperity]

So I read it correctly that --preanalyze-dir is by default same as <OUTPUT_DIR> (the name of the opstring is NOT report-dir but output-dir!), but we can set it to something else?

I don't like the phrase preanalyze-dir. A better string should be found, one that conveys the fact that extra analysis resources are stored here.