[cfe-dev] scan-build in python

Jordan Rose jordan_rose at apple.com
Fri Jan 3 09:14:49 PST 2014

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.

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

More information about the cfe-dev mailing list