db1eca94f6
The clang we ship no longer includes the static analyzer, so this flag hasn't been working for a while. Remove it, and mb stuff for an FYI bot that uses it. The plan is to run the static analyzer through clang-tidy instead. While here, also remove the 'win analyze' bot src bits, since that bot depends on MSVC which we haven't supported in a while either, and the little bit of GN code kept alive by it. Bug: 925145,687243 Change-Id: I042d3cc9f512a024a6eae6a8e7d43aa2f9a74fea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1538987 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by: Hans Wennborg <hans@chromium.org> Auto-Submit: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#644866}
3.0 KiB
The Clang Static Analyzer
The Clang C/C++ compiler comes with a static analyzer which can be used to find bugs using path sensitive analysis. Path sensitive analysis is a technique that explores all the possible branches in code and records the codepaths that might lead to bad or undefined behavior, like an uninitialized reads, use after frees, pointer leaks, and so on.
See the official Clang static analyzer page for more background information.
We used to have a bot that continuously ran with the static analyzer, but people used to not look at it much.
The static analyzer can still be invoked with clang-tidy.
Recommended checks
Clang's static analyzer comes with a wide variety of checkers. Some of the checks aren't useful because they are intended for different languages, platforms, or coding conventions than the ones used for Chromium development.
Checkers we found useful were:
-analyzer-checker=core
-analyzer-checker=cpp
-analyzer-checker=unix
-analyzer-checker=deadcode
As of this writing, the checker suites we support are core, cplusplus, and deadcode.
Addressing false positives
Some of the errors you encounter will be false positives, which occurs when the static analyzer naively follows codepaths which are practically impossible to hit at runtime. Fortunately, we have a tool at our disposal for guiding the analyzer away from impossible codepaths: assertion handlers like DCHECK/CHECK/LOG(FATAL). The analyzer won't check the codepaths which we assert are unreachable.
An example would be that if the analyzer detected the function argument
*my_ptr might be null and dereferencing it would potentially segfault, you
would see the error warning: Dereference of null pointer (loaded from variable 'my_ptr'). If you know for a fact that my_ptr will not be null in practice,
then you can place an assert at the top of the function: DCHECK(my_ptr). The
analyzer will no longer generate the warning.
Be mindful about only specifying assertions which are factually correct! Don't DCHECK recklessly just to quiet down the analyzer. :)
Other types of false positives and their suppressions:
- Unreachable code paths. To suppress, add the
ANALYZER_SKIP_THIS_PATH();directive to the relevant code block. - Dead stores. To suppress, use the macro
ANALYZER_ALLOW_UNUSED(my_var). This also suppresses dead store warnings on conventional builds without static analysis enabled!
See the definitions of the ANALYZER_* macros in base/logging.h for more
detailed information about how the annotations are implemented.
Logging bugs
If you find any issues with the static analyzer, or find Chromium code behaving
badly with the analyzer, please check the Infra>CodeAnalysis CrBug component
to look for known issues, or file a bug if it is a new problem.