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

[Artem Dergachev via cfe-dev]

On 12/10/18 8:57 AM, Kristóf Umann via cfe-dev wrote:
> 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.
> https://reviews.llvm.org/D55424
>
> 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.
> https://reviews.llvm.org/D54438
> https://reviews.llvm.org/D55429

Aren't we doing dependencies via Checkers.td?


>
> 3. CheckerRegistry was moved from the Core directory to Frontend.
> https://reviews.llvm.org/D54436
>
> ===--- 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.
> https://reviews.llvm.org/D53483
>
> 2. There is a new -analyzer-config-help flag to list all non-checker 
> configurations.
> https://reviews.llvm.org/D53296
>
> 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.
> https://reviews.llvm.org/D53280
>
> 4. Similar plans are already in motion to make checker options 
> similarly strict.
>
> Cheers,
> Kristóf Umann
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181210/06c1da8e/attachment.html>