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

[Kristóf Umann via cfe-dev]

On Mon, 10 Dec 2018, 21:58 Artem Dergachev <noqnoqneo at gmail.com wrote:

>
>
> 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?
>
I should've been more clear: in the official repo yes, and I guess using
the same method out-of-tree is the easiest solution, but essentially this
is what happening under the hood.

>
>
> 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 listcfe-dev at lists.llvm.orghttp://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/0b29c475/attachment.html>