[PATCH] D54397: [analyzer][NFC] Move CheckerOptInfo to CheckerRegistry.cpp, and make it local

Umann Kristóf via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Nov 11 12:26:47 PST 2018

Szelethus created this revision.
Szelethus added reviewers: NoQ, george.karpenkov, xazax.hun, rnkovacs, MTC.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, whisperity.

TL;DR: `CheckerOptInfo` feels very much out of place in `CheckerRegistration.cpp`, so I moved it to `CheckerRegistry.h`.


While on the quest of fixing checker options the same way I cleaned up non-checker options, although I'm making good progress, I ran into a wall: In order to emit warnings on incorrect checker options, we need to ensure that checkers actually acquire their options properly -- but, I unearthed a huge bug in checker registration: dependencies are currently implemented in a way that breaks the already very fragile registration infrastructure.

Here is where the problem really originates from: this is a snippet from `CheckerRegistry::initializeManager`.

  // Initialize the CheckerManager with all enabled checkers.
  for (const auto *i :enabledCheckers) {

Note that `Initialize` is a function pointer to `register##CHECKERNAME`, like `registerInnerPointerChecker`. Since for each register function call the current checker name is only set once, when `InnerPointerChecker` attempts to also register it's dependent `MallocChecker`, both it and `MallocChecker` will receive the `cplusplus.InnerPointer` name. This results in `MallocChecker` trying to acquire it's `Optimistic` option as `cplusplus.InnerPointerChecker:Optimistic`.

Clearly, this problem has to be solved at a higher level -- it makes no sense to be affect other checkers in a registry function. Since I'll already make changes to how checker registration works, I'll probably tune some things for the current C++ standard, add much needed documentation, and try to make the code //a lot less confusing//.

  rC Clang



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D54397.173568.patch
Type: text/x-patch
Size: 9800 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181111/64ff4a13/attachment.bin>

More information about the cfe-commits mailing list