Running linters and static analysers

Linters and analysers

Clang Static Analyzer

From the command line

Your Clang installation should have come with a script called scan-build. This may have different names in some package managers. For example, in MacPorts, the script belonging to Clang 11 is called scan-build-mp-11.

scan-build will set the CC and CXX environment variables to a special compiler executable that generates analysis reports, runs the build tool given as its argument, then collects those reports and creates an interactive webpage to browse them.

Note by @szhorvat: There are reports that older versions may require make instead of ninja. I verified that the analyser included with Clang 11 works with ninja.

Assuming ninja as the build tool,

scan-build cmake -GNinja ..
scan-build ninja

You should now see each problem output to the terminal. When the build is finished, scan-build will output instructions on how to view the final report in a web browser. Example:

scan-build: 93 bugs found.
scan-build: Run 'scan-view /var/folders/31/l_62jfs110lf0dh7k5n_y2th0000gq/T/scan-build-2021-05-12-160823-64252-1' to examine bug reports.

Follow these instructions to get an interactive webpage, and remember that scan-view may also have an alternative name on your system.

Run within Xcode

Browsing the reports is more convenient within Xcode. First, create an Xcode project with CMake:

cmake -GXcode ..

Note: Recent versions of Xcode enable many strict warnings, thus passing -DIGRAPH_WARNINGS_AS_ERRORS=OFF is necessary for successful analysis.

Now open it:

open igraph.xcodeproj

Xcode will ask whether to automatically create schemes. It is fine (and quickest) to confirm this.

To run the analyser, within Xcode, choose Product -> Analyze.

By default, this will use Xcode's default Clang version. To permanently patch Xcode to use a different (perhaps newer) Clang build, use the set-xcode-analyzer script which comes with LLVM Clang. For example,

set-xcode-analyzer --use-checker-build=/opt/local/libexec/llvm-11/

The --use-checker-build argument must point not to an executable, but to the root directory of the Clang installation.

cppcheck

Within a clean build directory:

cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..

Now build the parsersources target, e.g. ninja parsersources. cppcheck needs to have all files in places before it will run.

Run cppcheck:

cppcheck --project=compile_commands.json --xml 2> err.xml

You may use -j4 or similar to run 4 parallel threads at the same time.

Generate a HTML report

cppcheck-htmlreport --file=err.xml --report-dir=report --source-dir=.

GCC's static analyzer

Simply add -fanalyzer to the compilation options.

It is best to use make (i.e. cmake -G'Unix Makefiles') in order to allow coloured output. GCC will write its report to the terminal, so colouring is very helpful in interpretation.

As of 2022-03-19, GCC finds many false positives in strvector.c.

Coverity

A Coverity scan is run automatically once per day. It may also be triggered manually in GitHub Actions. Please do not trigger it more than twice per day, otherwise igraph's quota will be exceeded and the scheduled run will fail.

You can request access to the scan results here.

clang-tidy

CMake has clang-tidy integration.

Example use:

CT='clang-tidy;--use-color;--checks=misc-no-recursion' cmake .. -DCMAKE_C_CLANG_TIDY=$CT -DCMAKE_CXX_CLANG_TIDY=$CT

Note that the clang-tidy command and its arguments must be separated by ;, as we're building a CMake list.

Relevant options:

• --use-color produces coloured output
• --checks takes a comma-separated list of check names to be enabled or disabled. Prefixing a check name with - disables it. Wildcards are accepted, so --checks=-* would disable all checks, after which specific checks can be enabled.