[cfe-dev] scan-build in python
Laszlo Nagy
rizsotto.mailinglist at gmail.com
Thu May 22 01:01:27 PDT 2014
hi Jordan,
hi all,
i have a question related to ccc-analyzer. it is about the `Analyze` method
(line 272). it does check the `$IncludeParserRejects` variable, which is
initialized to zero once and has a comment "Set this to 1 if we want to
include 'parser rejects' files." my question is: who will set that to 1?
shall it be an environment which turn this on? can i leave it out from the
rewritten version?
thanks,
Laszlo
ps.: today i could fetch the attached file. thanks for that!
On Thu, May 1, 2014 at 5:30 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> Here it is:
> https://attache.apple.com/AttacheWeb/dl?id=ATCf722062eedd34dba96a56bde1310ed41&ek=ATChtmkeWLieQe1gA7V22FwhA%3D%3D<https://attache.apple.com/AttacheWeb/dl?id=ATCf722062eedd34dba96a56bde1310ed41&ek=ATChtmkeWLieQe1gA7V22FwhA==>
>
> (no promises about the lifetime of that link to anyone discovering this
> e-mail in the cfe-dev archives in the future)
>
> It's just a snapshot of a few open-source projects, along with reference
> results (which I regenerated before making the archive). Unfortunately, we
> haven't gone through all the results on a recent analyzer build to verify
> that they're all desired or have bugs filed, but for testing output
> identity it should be good enough. The tests are meant to be run with
> utils/analyzer/SATestBuild.py, with scan-build and clang in your path.
>
> It's a small number of projects, unfortunately, so it's not really
> exercising scan-build that much, but it's something.
>
> Jordan
>
>
> On Apr 23, 2014, at 12:09 , Laszlo Nagy <rizsotto.mailinglist at gmail.com>
> wrote:
>
> 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/20140522/3009d8fc/attachment.html>
More information about the cfe-dev
mailing list