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

[Kristóf Umann via cfe-dev]

I sadly won't be able to dedicate enough time to overcome some hurdles that
stop me from commiting these things before the creation of the 8.0 branch,
so it'll only land in the next major release.

Kristóf Umann <dkszelethus at gmail.com> ezt írta (időpont: 2018. dec. 10., H,
22:08):

> 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/20190111/143b73af/attachment.html>