Do we really need clang-sa while clang-tidy does the same and more?

[irishrover]

Disclaimer. There's a possibly stupid question below :-)

So we have:

• clang-tidy who can invoke any clangSA checks (clang-analyzer-*),
• CodeChecker who can convert clang-tidy output into plist and html,
• clang-tidy who is usually faster than clangSA.

So why we still use clangSA? Did I miss something?

[gyorb]

Without going to much into the details. There are a lot of features in clang SA which are not available in clang tidy and can be only configured or used through clang SA:

• Cross Translation Unit Analysis
• Z3 theorem prover can be used to replace (really slow right now) the built-in range based solver, or just to double check/refute the results to reduce false positives (refutation does not increases the analysis time too much)
• checker plugins (write checkers in an shared object)
• I'm not sure how a multi file static analyzer report is generated in clang-tidy's text based output
• option to expand macros in the analyzer reports (this is a clang static analyzer option which can help to understand the reports)
• there are a lot of analyzer configuration options for clang SA (some of them are documented here). I'm not sure they can be configured through clang-tidy, (I think only checker options can be configured)

clang-tidy checkers are usually faster because they use only AST matching to find errors.
For a more deeper analysis (symbolic execution, considering the possible values of variables) the framework is in the clang static analyzer, that is why the analysis is slower there.
There are checkers which can be only implemented in clang static analyzer (technically every clang-tidy checker could be implemented in clang SA).

[irishrover]

Well, thanks. My disclaimer was reasonable :-)