[cfe-dev] scan-build in python

[Laszlo Nagy]

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