This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by Szelethus on Feb 28 2020, 8:56 AM.

Details

Summary

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).

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.

Diff Detail

Event Timeline

Szelethus created this revision.Feb 28 2020, 8:56 AM
Szelethus updated this revision to Diff 247291.Feb 28 2020, 9:22 AM

Unforget git add.

Phabricator didn't pick up on it (because I accidentally used mv instead of git mv), but CheckerRegistration.h was moved to AnalyzerHelpFlags.h.

clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
171

Please mark these getters as const.

I do not say I fully grab every single character, but basically it looks good to me. @NoQ, please take a look on this, you are more competent in finding issues with it. This patch is needed to my patch preventing registration of checkers that depend on an analyzer option. Thx!

clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
221

Why do we need MGR here as template parameter? Is this function also used for other class instances than CheckerManager? I fail to see such invocation.

Szelethus marked 2 inline comments as done.Mar 11 2020, 9:56 AM
Szelethus added inline comments.
clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
221

Include cycles :) CheckerManager.h includes CheckerRegistry.h, so we can only forward declare CheckerManager, hence the need for a template parameter.

NoQ added inline comments.Mar 15 2020, 9:00 PM
clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
221

Maybe put the implementation into the cpp file instead?

clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
33

Why?

Szelethus marked 3 inline comments as done.Mar 16 2020, 3:33 AM
Szelethus added inline comments.
clang/include/clang/StaticAnalyzer/Frontend/AnalyzerHelpFlags.h
2–11

This is all incorrect.

clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
33

clangd >.< Nice catch, I'll remove it.

clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
221

+1 Using templates where only one template parameter is possible is overkill and makes the code difficult to understand.

Szelethus marked an inline comment as done.Mar 18 2020, 4:33 AM
Szelethus added inline comments.
clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
221

Can't do, mind that the checker is a template parameter as well. I could add more comments tho!

Szelethus updated this revision to Diff 251053.Mar 18 2020, 6:00 AM

Address inlines.

Szelethus updated this revision to Diff 251056.Mar 18 2020, 6:17 AM

Seems like D75171 didn't add const methods after all, here they are.

Szelethus marked 4 inline comments as done.Mar 18 2020, 6:20 AM
This revision is now accepted and ready to land.Mar 20 2020, 2:24 AM
This revision was automatically updated to reflect the committed changes.

It appears this broke the modules build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/12905/console

Can you please take a look?

It appears this broke the modules build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/12905/console

Can you please take a look?

Yup, on it.

It appears this broke the modules build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/12905/console

Can you please take a look?

Yup, on it.

Oh, I'm sorry, I just reverted it like a minute ago.

Szelethus reopened this revision.Mar 23 2020, 1:02 PM

Oh, I'm sorry, I just reverted it like a minute ago.

Its fine, I'll recommit when I have a fix as well :)

This revision is now accepted and ready to land.Mar 23 2020, 1:02 PM

Tried to recommit -- I'll keep a close eye on this.

This revision was automatically updated to reflect the committed changes.
clang/include/clang/StaticAnalyzer/Frontend/AnalyzerHelpFlags.h