Static Analyzer Checker Options Proposal

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) 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.

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?

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 disallowing this?

(Sorry for the duplicate e-mail, sent the first from the wrong e-mail address.)

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.

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.

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.