[cfe-dev] scan-build in python

Laszlo Nagy rizsotto.mailinglist at gmail.com
Fri Dec 27 14:56:17 PST 2013

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?

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.

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`.

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?


On Tue, Oct 22, 2013 at 8:59 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> On Oct 21, 2013, at 13:59, Laszlo Nagy <rizsotto.mailinglist at gmail.com> wrote:
>> thanks Jordan for the reply.
>>> This is the right list for analyzer questions. Ted Kremenek, Anna Zaks, and I are the primary maintainers.
>>> What in particular is broken in ccc-analyze / scan-build?
>> small thing i found, when `ccc-analyzer` processes the arguments, take
>> '-m.*' and put into the CompileOpts. then a few lines bellow there is
>> a CompilerLinkerOptionMap lookup which has 5 parameters starting with
>> '-m'. which implies they never gonna end up in CompileOpts _and_
>> LinkOpts.
> Ah, good catch! Fixed in r193184.
>> also wondered many times where are these flags coming from? like
>> '-arch'? clang/gcc does not have it. (found a few others which are
>> also not found in clang/gcc.) which compiler tries the 'ccc-analyze'
>> simulate?
> -arch is a Darwin-specific option that provides a shorthand for -target on a few common Apple architectures. It's only enabled if the default target triple is a Darwin OS.
> Jordan

More information about the cfe-dev mailing list