[PATCH] D75360: [analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, xazax.hun, baloghadamsoftware, rnkovacs, balazske, martong, dcoughlin.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, steakhal, Charusso, gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, whisperity, mgorny.

Its been a while since my `CheckerRegistry` related patches landed, allow me to refresh your memory:

- During compilation, TblGen turns `clang/include/clang/StaticAnalyzer/Checkers/Checkers.td` into `(build directory)/tools/clang/include/clang/StaticAnalyzer/Checkers/Checkers.inc`. This is a file that contains the full name of the checkers, their options, etc.
- The class that is responsible for parsing this file is `CheckerRegistry`. The job of this class is to establish what checkers are available for the analyzer (even from plugins and statically linked but non-tblgen generated files!), and calculate which ones should be turned on according to the analyzer's invocation.
- `CheckerManager` is the class that is responsible for the construction and storage of checkers. This process works by first creating a `CheckerRegistry` object, and passing itself to `CheckerRegistry::initializeManager(CheckerManager&)`, which will call the checker registry functions (for example `registerMallocChecker`) on it.

The big problem here is that these two classes lie in two different libraries, so their interaction is pretty awkward. This used to be far worse, but I refactored much of it, which made things better but nowhere near perfect.

---

This patch changes how the above mentioned two classes interact. `CheckerRegistry` is mainly used by `CheckerManager`, and they are so intertwined, it makes a lot of sense to turn in into a field, instead of a one-time local variable. This has additional benefits: much of the information that `CheckerRegistry` conveniently holds is no longer thrown away right after the analyzer's initialization, and opens the possibility to pass `CheckerManager` in the `shouldRegister*` function rather then `LangOptions` (D75271 <https://reviews.llvm.org/D75271>).

There are a few problems with this. `CheckerManager` isn't the only user, when we honor help flags like `-analyzer-checker-help`, we only have access to a `CompilerInstance` class, that is before the point of parsing the AST. `CheckerManager` makes little sense without `ASTContext`, so I made some changes and added new constructors to make it constructible for the use of help flags.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75360

Files:
  clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
  clang/include/clang/StaticAnalyzer/Frontend/AnalysisConsumer.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistration.h
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  clang/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalyzerHelpFlags.cpp
  clang/lib/StaticAnalyzer/Frontend/CMakeLists.txt
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D75360.247278.patch
Type: text/x-patch
Size: 25938 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200228/1c9242ff/attachment-0001.bin>