[cfe-dev] Static Analyzer Checker Options Proposal

[Anna Zaks]

This looks good to me. I was mainly thinking/talking about implicit inheritance. Improving the way checkers can query options is a definite plus.

Thanks for the suggestion!
Anna.
> On Oct 13, 2014, at 5:20 PM, Gabor Kozar <kozargabor at gmail.com> wrote:
> 
> How about the getOption() function getting a boolean parameter specifying whether to allow "inherited" options, with the default being true?
>  
> getOption("unix.stuff.moo.FooChecker", "MyOption", true) would then be equivalent to trying to all of these:
> unix.stuff.moo.FooChecker:MyOption
> unix.stuff.moo:MyOption
> unix.stuff:MyOption
> unix:MyOption
> I think this behavior would be clear and straight-forward.
>  
> ---
> Best regards,
>  
> Gábor 'ShdNx' Kozár
> http://gaborkozar.me <http://gaborkozar.me/>
>  
>  
>  
> On Tue, Oct 14, 2014, at 00:27, Anna Zaks wrote:
>>  
>>> On Oct 13, 2014, at 8:55 AM, Gabor Kozar <kozargabor at fastmail.fm <mailto: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 <mailto: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/20141014/59e1c8f4/attachment.html>