[PATCH] D80905: [analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order

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

Szelethus created this revision.
Szelethus added reviewers: NoQ, martong, balazske, xazax.hun, rnkovacs, baloghadamsoftware, dcoughlin.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, ASDenysPetrov, steakhal, Charusso, gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, whisperity.
Szelethus added a parent revision: D80901: [analyzer][NFC] Change checker dependency unit tests to check for the registration order.
Szelethus added a child revision: D78126: [analyzer][NFC] Don't allow dependency checkers to emit diagnostics.

Checker dependencies were added D54438 <https://reviews.llvm.org/D54438> to solve a bug where the checker names were incorrectly registered, for example, InnerPointerChecker would incorrectly emit diagnostics under the name MallocChecker, or vice versa [1]. Since the system over the course of about a year matured, our expectations of what a role of a dependency and a dependent checker should be crystallized a bit more -- D77474 <https://reviews.llvm.org/D77474> and its summary, as well as a variety of patches in the stack demonstrates how we try to keep dependencies to play a purely modeling role. In fact, D78126 <https://reviews.llvm.org/D78126> outright forbids diagnostics under a dependency checkers name.

These dependencies ensured the registration order and enabling only when all dependencies are satisfied. This was a very "strong" contract however, that doesn't fit the dependency added in D79420 <https://reviews.llvm.org/D79420>. As its summary suggests, this relation is directly in between diagnostics, not modeling -- we'd prefer a more specific warning over a general one.

To support this, I added a new dependency kind, weak dependencies. These are not as strict of a contract, they only express a preference in registration order. If a weak dependency isn't satisfied, the checker may still be enabled, but if it is, checker registration, and transitively, checker callback evaluation order is ensured.

If you are not familiar with the TableGen changes, a rather short description can be found in the summary of D75360 <https://reviews.llvm.org/D75360>. A lengthier one is in D58065 <https://reviews.llvm.org/D58065>. Of course, this is a rather rarely touched part of the analyzer and I'm happy to spill the beans if any part of it is unclear!

[1] https://www.youtube.com/watch?v=eqKeqHRAhQM


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80905

Files:
  clang/include/clang/StaticAnalyzer/Checkers/CheckerBase.td
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  clang/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
  clang/test/Analysis/weak-dependencies.c
  clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
  clang/utils/TableGen/ClangSACheckersEmitter.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D80905.267539.patch
Type: text/x-patch
Size: 30501 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200601/a9e9fdfa/attachment-0001.bin>