[cfe-dev] Static Analyzer Checker Options Proposal
Anna Zaks
ganna at apple.com
Mon Oct 13 16:27:38 PDT 2014
> On Oct 13, 2014, at 8:55 AM, Gabor Kozar <kozargabor at fastmail.fm> wrote:
>
> However, there will be no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct from the setting ‘unix.Malloc:Optimistic’).
>
> I think inheritance like that could be useful in some situations.
The main reason is that we currently do not have a need for it and allowing inheritance requires a design for it. For example, what happens when a package adds an option? How would the checkers access it? If we were to allow dynamically loaded checkers how would they inherit it? What happens if a checker overrides a package option?
> I would expect such options to be inherited, i.e. if I set 'unix:Optimistic', then I expect this to be visible everywhere in the 'unix' package. Why are disallowing this?
>
The package options will be visible to checkers; specifically, checkers could query the package options. For example, MallocChecker could call getOption(Optimistic, "unix") to check if the option has been set on the package.
> (Sorry for the duplicate e-mail, sent the first from the wrong e-mail address.)
>
> ---
> Best regards,
>
> Gábor 'ShdNx' Kozár
> http://gaborkozar.me <http://gaborkozar.me/>
>
>
> On Mon, Oct 13, 2014, at 15:59, Gabor Kozar wrote:
>> However, there will be no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct from the setting ‘unix.Malloc:Optimistic’).
>>
>> I think inheritance like that could be useful in some situations. I would expect such options to be inherited, i.e. if I set 'unix:Optimistic', then I expect this to be visible everywhere in the 'unix' package. Why are you proposing to disallow this?
>>
>> ---
>> Best regards,
>>
>> Gábor 'ShdNx' Kozár
>> http://gaborkozar.me <http://gaborkozar.me/>
>>
>>
>>
>> On Sat, Oct 11, 2014, at 01:17, Anna Zaks wrote:
>>> Background & Problem:
>>>
>>> Clang has support for static analyzer options though "-analyzer-config”
>>> front-end option, which is followed by the option name and value:
>>> -analyzer-config <Option Name>=<Value>
>>> This option is also available through scan-build.
>>>
>>> Currently, there is no way to pass command line options to specific
>>> checkers. We work around it by creating new checker kinds (for example,
>>> MallocPessimistic, MallocOptimistic).
>>>
>>> Proposed Solution:
>>>
>>> The proposal (partially authored and implemented by Aleksei Sidorin
>>> http://reviews.llvm.org/D3967 <http://reviews.llvm.org/D3967>) is to extend "-analyzer-config" to support
>>> checker-specific options as following:
>>> -analyzer-config <Full Checker Name / Package Name>:<Option
>>> Name>=<Value>
>>>
>>> To avoid ambiguities with regular options, we should enforce the
>>> following:
>>> 1) <Option Name> should be an identifier
>>> 2) Checker names should be identifiers.
>>> 3) Package names should be identifiers joined with '.’.
>>> 4) <Full Checker Name> has the same form as package names.
>>>
>>> Specifying options on a package will be allowed. However, there will be
>>> no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct
>>> from the setting ‘unix.Malloc:Optimistic’). Each checker will be able to
>>> query options of its package when needed. For this, we propose changing
>>> the getOption API to work with package and checker names as well as
>>> CheckerBase.
>>>
>>> Comments and suggestions are welcome!
>>> Anna.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141013/79064a86/attachment.html>
More information about the cfe-dev
mailing list