[cfe-dev] scan-build in python

Jordan Rose jordan_rose at apple.com
Wed Apr 23 10:00:50 PDT 2014


We have a test suite, but it has internal Apple projects as well as open-source projects. I can either run the suite locally with your changed ccc-analyzer or try to strip out the internal parts...what would you prefer?

Jordan


On Apr 22, 2014, at 7:35 , Laszlo Nagy <rizsotto.mailinglist at gmail.com> wrote:

> hi Jordan,
> hi All,
> 
> to continue with the python rewrite on the 'scan-build'. i reached to
> the point when the 'ccc-analyzer' and 'c++-analyzer' re-implemented.
> now i would like to do some regression testing. (to compare the output
> of the perl and python implementation.) my question would be: is there
> any test suite against scan-build which is suitable for such test?
> 
> regards,
> Laszlo
> 
> On Fri, Jan 3, 2014 at 6:14 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> On Dec 27, 2013, at 14:56 , Laszlo Nagy <rizsotto.mailinglist at gmail.com>
>> wrote:
>> 
>> hi Jordan,
>> hi everyone,
>> 
>> i'm still trying the python rewrite of `scan-build` and found things
>> which does not seem logical to me. could you help me to understand
>> these issues?
>> 
>> 
>> Hi, Laszlo. Thanks for doing this.
>> 
>> 
>> ccc-analyzer: Analyze method around line 197. it appends
>> `-analyzer-display-progress` to a list with `-Xclang`. and next to it
>> there is a for loop which injects `-Xclang` infront of the arguments.
>> which will end up 3 times `-Xclang`. if i read it correctly.
>> 
>> 
>> The loop iterates over @AnalyzeArgs rather than @Args, which is coming in
>> from outside the function. We could push onto @AnalyzeArgs within the
>> Analyze routine and then have a single "-Xclang"-adding pass, but this way
>> is not incorrect. Feel free to restructure the function in your rewrite,
>> though.
>> 
>> 
>> ccc-analyzer: Analyze method around line 174. it checks language match
>> to `header`. i think it never will have that value. because the caller
>> of that method takes the language from the given parameters. (it can't
>> be detected by file name extension, since `%LangMap` does not have
>> 'header' value.) and then call the `Analyze` method only if the
>> language is one of those declared in `%LangsAccepted`.
>> 
>> 
>> I would guess this is a holdover from when Xcode would invoke the compiler
>> to process PCH files (notice the reference to "gch"). I agree with your
>> diagnosis that this is now dead code.
>> 
>> 
>> and i have an extra question. :) why there is a lookup for default
>> compiler? (the value of `$Compiler`) to me it does not seems logical
>> to forward even the original arguments to `gcc` when we try to run
>> `clang` afterwards. in case of the sources compile only with `gcc`,
>> then Clang's static analyser will report problem. (what report will be
>> that?) in case of the source compiles only with Clang, then
>> `scan-build` crashes the build on `gcc`. wouldn't be more
>> consistent/less error-prone to call always `clang` on every platform?
>> 
>> 
>> Clang and GCC have largely-compatible interfaces, but at the time scan-build
>> was written Clang wasn't up to par with GCC in a lot of ways. (It is an old
>> program.) Even today, it's still possible to have programs that compile with
>> GCC but not with Clang. Since scan-build is interposing on the build
>> process, we still need to build those files, and therefore we should choose
>> the compiler most likely to compile them, even if it means we can't analyze
>> a particular file. Always choosing Clang would mean that some projects would
>> fail to build, which could cause downstream issues and keep us from
>> analyzing every file after this one.
>> 
>> That said, Clang is now the default compiler on OS X, so we use that as the
>> default when running scan-build there. But mostly it's just a guess: what's
>> most likely the best option on this platform? As much as we like Clang, the
>> answer is probably still GCC.
>> 
>> That said, it would remove complexity to just say "we can only analyze your
>> project if it builds with Clang". Ted, Anna, and I have talked about that
>> idea before. But there's no urgent need to switch.
>> 
>> Jordan




More information about the cfe-dev mailing list