[cfe-dev] [analyzer] Tighter command line interface, new API to register dependencies

Kristóf Umann via cfe-dev cfe-dev at lists.llvm.org
Mon Dec 10 08:57:05 PST 2018

Hi all!

This mail is a heads up for out-of-tree checker developers that I'm
planning to land a variety of changes to how checker registration works.
Also, I already commited some changes to make the command line interface a
little less annoying. While I will properly document most of these in some
form or another with a file in the actual repo, I'll leave about a week for
everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple
checkers receiving the same name. The solution was to reimplement parts on
the checker registration process.

1. From now, all checkers should have a corresponding
shouldRegister##CHECKERNAME function defined, similar to
register##CHECKERNAME. The intent here is that once a registry function is
called, it should register the checker. If based on some language options
you chose not to register your checker within register##CHECKERNAME, please
move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one
checker. Also, CheckerManager::registerChecker<CHECKER> may only be called
once per checker. If you intend to acquire a checker object within a
registry function (for example, if it merely enables extension to the main
checker), please use CheckerManager::getChecker<CHECKER>. You can ensure
that the checker you'd like to acquire is already registered by adding it
as a dependency via CheckerRegistry::addDependency.

3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying
issue that any invalid input would be ignored and the analyzer simply
didn't do what you want -- this is changing. Please note that most of these
have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without
modifying the actual implementation, which can be done by writing a new
entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker

3. A new flag was added that will emit a warning on almost any invalid
-analyzer-config input, called -analyzer-config-compatibility-mode. When
the analyzer is invoked with -analyze (in driver mode, I'm unsure about the
correct terminology), it will be set to false by default, but will be
enabled with -cc1 (in frontend mode). You may enable this feature in the
driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly

Kristóf Umann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181210/305c8f03/attachment.html>

More information about the cfe-dev mailing list