[all-commits] [llvm/llvm-project] b6cbe6: [analyzer][NFC] Move the data structures from Chec...

[Kristóf Umann via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: b6cbe6cb0399d4671e5384dcc326af56bc6bd122
      https://github.com/llvm/llvm-project/commit/b6cbe6cb0399d4671e5384dcc326af56bc6bd122
  Author: Kirstóf Umann <dkszelethus at gmail.com>
  Date:   2020-07-04 (Sat, 04 Jul 2020)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
    A clang/include/clang/StaticAnalyzer/Core/CheckerRegistryData.h
    M clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
    M clang/lib/StaticAnalyzer/Core/CMakeLists.txt
    A clang/lib/StaticAnalyzer/Core/CheckerRegistryData.cpp
    M clang/lib/StaticAnalyzer/Core/Environment.cpp
    M clang/lib/StaticAnalyzer/Frontend/AnalyzerHelpFlags.cpp
    M clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
    M clang/lib/StaticAnalyzer/Frontend/CreateCheckerManager.cpp
    M clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp

  Log Message:
  -----------
  [analyzer][NFC] Move the data structures from CheckerRegistry to the Core library

If you were around the analyzer for a while now, you must've seen a lot of
patches that awkwardly puts code from one library to the other:

* D75360 moves the constructors of CheckerManager, which lies in the Core
  library, to the Frontend library. Most the patch itself was a struggle along
  the library lines.
* D78126 had to be reverted because dependency information would be utilized
  in the Core library, but the actual data lied in the frontend.
  D78126#inline-751477 touches on this issue as well.

This stems from the often mentioned problem: the Frontend library depends on
Core and Checkers, Checkers depends on Core. The checker registry functions
(`registerMallocChecker`, etc) lie in the Checkers library in order to keep each
checker its own module. What this implies is that checker registration cannot
take place in the Core, but the Core might still want to use the data that
results from it (which checker/package is enabled, dependencies, etc).

D54436 was the patch that initiated this. Back in the days when CheckerRegistry
was super dumb and buggy, it implemented a non-documented solution to this
problem by keeping the data in the Core, and leaving the logic in the Frontend.
At the time when the patch landed, the merger to the Frontend made sense,
because the data hadn't been utilized anywhere, and the whole workaround without
any documentation made little sense to me.

So, lets put the data back where it belongs, in the Core library. This patch
introduces `CheckerRegistryData`, and turns `CheckerRegistry` into a short lived
wrapper around this data that implements the logic of checker registration. The
data is tied to CheckerManager because it is required to parse it.

Side note: I can't help but cringe at the fact how ridiculously awkward the
library lines are. I feel like I'm thinking too much inside the box, but I guess
this is just the price of keeping the checkers so modularized.

Differential Revision: https://reviews.llvm.org/D82585