[cfe-dev] improvements to scan-build

[Anton Yartsev]

Thanks for looking at this!

>
>> On Nov 6, 2014, at 9:35 AM, Jordan Rose <jordan_rose at apple.com 
>> <mailto: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.
I'll think this over. May Class::Struct fit or just simple options renaming.

>>
>>
>>>
>>> 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) 
>>> 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?
As for me I got tired copying this wrappers with repetitive options 
around :)
All my scan-build invocations start with '-v -v -v -o "./" 
--use-analyzer=F:/llvm_COMMON/-Eclipse_build-/Release+Asserts/bin/clang.exe 
-analyze-headers'. I'd be glad to move this to config.

>>
>>
>>>
>>> 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.
Not CFLAGS but some special variable known only for scan-build and 
ccc/c++-analyzer scripts. This variable doesn't need to be an 
environment variable, ccc/c++-analyzer may read its value directly from 
the configuration file. This flags must be given to Clang only, not GCC 
or other compiler.

>>
>> 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.
Ok, I'll explore the behavior of clang with --analyze more carefully. 
I've faced an unsupported option while trying to build QT, unfortunately 
can not find what this option was.
The idea to move this setting to config was to give the user more 
freedom in customization (for example if the user face an unsupported 
flag that is not handled by "clang --analyze" logic then he can simply 
disable passing this option to clang using config file).
The second reason for adding this option to config were my dim memories 
about non-analyzer specific flags that affected analyzer behavior. I may 
be mistaken here. Perhaps this were optimization options. I thought It 
would be good to have an ability to disable this options.

>
> Also, note that build time is usually small in comparison to the 
> analysis time.
>
>>
>> Jordan
>
-- 
Anton

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