[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