[cfe-dev] scan-build in python

[Laszlo Nagy]

thanks Jordan for your reply. i would be interested in the striped version
of the test set. it would give me more more insights how the current
implementation works. (i do not trust my perl reading skill :))


On Wed, Apr 23, 2014 at 7:00 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140423/eed64d49/attachment.html>