[cfe-dev] Static Analyzer Checker Options Proposal

[Gabor Kozar]

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
[1]http://gaborkozar.me





On Tue, Oct 14, 2014, at 00:27, Anna Zaks wrote:



On Oct 13, 2014, at 8:55 AM, Gabor Kozar
<[2]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
[3]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
[4]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

[5]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

[6]cfe-dev at cs.uiuc.edu

[7]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________

cfe-dev mailing list

[8]cfe-dev at cs.uiuc.edu

[9]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[10]cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

References

1. http://gaborkozar.me/
2. mailto:kozargabor at fastmail.fm
3. http://gaborkozar.me/
4. http://gaborkozar.me/
5. http://reviews.llvm.org/D3967
6. mailto:cfe-dev at cs.uiuc.edu
7. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
8. mailto:cfe-dev at cs.uiuc.edu
9. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  10. mailto:cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141014/8a345d8d/attachment.html>