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.
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.
A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker 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. You can ensure that the checker you’d like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.
- 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.
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.
There is a new -analyzer-config-help flag to list all non-checker configurations.
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.
Similar plans are already in motion to make checker options similarly strict.