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

[Kristóf Umann via cfe-dev]

Sorry for the spam, hit send too early :/ when loading an external plugin,
you can register your checkers with the supplied CheckerRegistry object,
and my target audience was developers of external plugins, for example, us
in Ericsson.

I guess for developers working here on the official repo, visiting the
phabricator links or waiting for me to get together that documentation
would be the best course of action :)

On Mon, 10 Dec 2018, 22:00 Kristóf Umann <dkszelethus at gmail.com wrote:

>
>
> 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/81eec4fb/attachment.html>