[cfe-dev] improvements to scan-build

[Anna Zaks]

> On Nov 6, 2014, at 9:35 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Oct 27, 2014, at 13:30 , Anton Yartsev <anton.yartsev at gmail.com <mailto:anton.yartsev at gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> I'm thinking of the following improvements to scan-build and want to discuss them with the community and to hear your thoughts and opinions:
>> 
>> First of all, refactoring: keep all scan-build arguments in the hash rather then in scattered variables.
>> This will make the scan-build code easier to understand and make it easier to re-engineer the code in the future.
> 
> I'm not convinced of this. Either you have scattered options globally, or you have options in one place looked up by scattered string keys. I'd honestly prefer the globals because they'll let me know if I have a typo.
> 
> 
>> 
>> Then I intend to add a possibility for scan-build to read options from a simple INI-like (http://en.wikipedia.org/wiki/INI_file <http://en.wikipedia.org/wiki/INI_file>) configuration file.
>> Values (if any) from this file will override default hardcoded values but do not override those obtained from the command line.
>> The file may have separate sections for scan-build, ccc/c++-analyzer and environment variables (if needed).
>> This will concentrate all the analyzer settings in the single place and will allow users to easily observe the default values all-together and to customize scan-build invocations of their own will.
> 
> This seems reasonable. At the very least recording specific checkers to turn on or off makes sense. On the other hand, if it's just things that can be controlled on the command line, does it really offer that much more flexibility than someone writing their own wrapper scan.sh / scan.bat?
> 
> 
>> 
>> I also intend to add several additional options to scan-build:
>> 1) Set of additional flags for ccc/c++-analyzer (e.g. additional include paths, defines, optimization options, e.t.c).
>> Often after 'configure' analysys with Clang ended up with different errors and I had to manually patch makefiles to transfer additional flags to Clang to make it work. It was a real headache.
>> Here is random example of how this additional flags looked like: '-g0 -Os -fpermissive -D__STRICT_ANSI__ -I "F:/---OGRE/ogre_src_v1-8-1/include" -I "F:/---OGRE/ogre_src_v1-8-1/OgreMain/include"'...
>> So many times I wished to put extra flags somewhere so that ccc/c++-analyzer could take them and pass to Clang!
>> In configuration file it might look like the following:
>> CLANG_EXTRA_CXXFLAGS = -g0 -Os -fpermissive -D__STRICT_ANSI__ -I "F:/---OGRE/ogre_src_v1-8-1/include" -I "F:/---OGRE/ogre_src_v1-8-1/OgreMain/include"
> 
> I don't think this is a good idea. Most configure systems will pull CFLAGS or similar from the environment or from their command-line arguments. You should just use that.
> 
> scan-build make CFLAGS=-D__STRICT_ANSI__
> 
> 
>> 2) If it happens so that both gcc and Clang are used after configuration then they share the same set of flags and the problem increases - Clang do not recognize some of gcc flags.
>> So I wish to add another option to scan-build, (e.g. CLANG_EXCLUDE_CXXFLAGS in config file) that will hold flags to be excluded from Clang invocation.
> 
> Last I heard we still strive to be GCC-compatible, so we should accept and warn/ignore any flags that GCC supports that we don't. But I can see how that doesn't solve the problem for a local user.
> 
> 
>> 3) The third option is to add a possibility to completely bypass compilation step by gcc(g++, etc.) - this partially solves problems with options and, what is more important, may significantly reduce overall analisys time.
> 
> Seems fair. It should still default to off (and we have to figure out if we can support it in Xcode), but it seems like a reasonable option.
> 

I'd like to clarify this point a bit. Some builds rely on the result of compilation. So if this option was added, it would be turned off by default. I agree with Jordan that the approach we should take is to teach scan-build about the options that need to be ignored when calling "clang --analyze". I think this is what it is already doing.

Also, note that build time is usually small in comparison to the analysis time.

> 
> Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141106/a5f6be8f/attachment.html>