<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Here it is: <a href="https://attache.apple.com/AttacheWeb/dl?id=ATCf722062eedd34dba96a56bde1310ed41&ek=ATChtmkeWLieQe1gA7V22FwhA==">https://attache.apple.com/AttacheWeb/dl?id=ATCf722062eedd34dba96a56bde1310ed41&ek=ATChtmkeWLieQe1gA7V22FwhA%3D%3D</a></div><div><br></div><div>(no promises about the lifetime of that link to anyone discovering this e-mail in the cfe-dev archives in the future)</div><div><br></div><div>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.</div><div><br></div><div>It's a small number of projects, unfortunately, so it's not really exercising scan-build that much, but it's something.</div><div><br></div><div>Jordan</div><div><br></div><br><div><div>On Apr 23, 2014, at 12:09 , Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com">rizsotto.mailinglist@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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 :))</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 23, 2014 at 7:00 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jordan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Apr 22, 2014, at 7:35 , Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com">rizsotto.mailinglist@gmail.com</a>> wrote:<br>
<br>
> hi Jordan,<br>
> hi All,<br>
><br>
> to continue with the python rewrite on the 'scan-build'. i reached to<br>
> the point when the 'ccc-analyzer' and 'c++-analyzer' re-implemented.<br>
> now i would like to do some regression testing. (to compare the output<br>
> of the perl and python implementation.) my question would be: is there<br>
> any test suite against scan-build which is suitable for such test?<br>
><br>
> regards,<br>
> Laszlo<br>
><br>
> On Fri, Jan 3, 2014 at 6:14 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
>><br>
>> On Dec 27, 2013, at 14:56 , Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com">rizsotto.mailinglist@gmail.com</a>><br>
>> wrote:<br>
>><br>
>> hi Jordan,<br>
>> hi everyone,<br>
>><br>
>> i'm still trying the python rewrite of `scan-build` and found things<br>
>> which does not seem logical to me. could you help me to understand<br>
>> these issues?<br>
>><br>
>><br>
>> Hi, Laszlo. Thanks for doing this.<br>
>><br>
>><br>
>> ccc-analyzer: Analyze method around line 197. it appends<br>
>> `-analyzer-display-progress` to a list with `-Xclang`. and next to it<br>
>> there is a for loop which injects `-Xclang` infront of the arguments.<br>
>> which will end up 3 times `-Xclang`. if i read it correctly.<br>
>><br>
>><br>
>> The loop iterates over @AnalyzeArgs rather than @Args, which is coming in<br>
>> from outside the function. We could push onto @AnalyzeArgs within the<br>
>> Analyze routine and then have a single "-Xclang"-adding pass, but this way<br>
>> is not incorrect. Feel free to restructure the function in your rewrite,<br>
>> though.<br>
>><br>
>><br>
>> ccc-analyzer: Analyze method around line 174. it checks language match<br>
>> to `header`. i think it never will have that value. because the caller<br>
>> of that method takes the language from the given parameters. (it can't<br>
>> be detected by file name extension, since `%LangMap` does not have<br>
>> 'header' value.) and then call the `Analyze` method only if the<br>
>> language is one of those declared in `%LangsAccepted`.<br>
>><br>
>><br>
>> I would guess this is a holdover from when Xcode would invoke the compiler<br>
>> to process PCH files (notice the reference to "gch"). I agree with your<br>
>> diagnosis that this is now dead code.<br>
>><br>
>><br>
>> and i have an extra question. :) why there is a lookup for default<br>
>> compiler? (the value of `$Compiler`) to me it does not seems logical<br>
>> to forward even the original arguments to `gcc` when we try to run<br>
>> `clang` afterwards. in case of the sources compile only with `gcc`,<br>
>> then Clang's static analyser will report problem. (what report will be<br>
>> that?) in case of the source compiles only with Clang, then<br>
>> `scan-build` crashes the build on `gcc`. wouldn't be more<br>
>> consistent/less error-prone to call always `clang` on every platform?<br>
>><br>
>><br>
>> Clang and GCC have largely-compatible interfaces, but at the time scan-build<br>
>> was written Clang wasn't up to par with GCC in a lot of ways. (It is an old<br>
>> program.) Even today, it's still possible to have programs that compile with<br>
>> GCC but not with Clang. Since scan-build is interposing on the build<br>
>> process, we still need to build those files, and therefore we should choose<br>
>> the compiler most likely to compile them, even if it means we can't analyze<br>
>> a particular file. Always choosing Clang would mean that some projects would<br>
>> fail to build, which could cause downstream issues and keep us from<br>
>> analyzing every file after this one.<br>
>><br>
>> That said, Clang is now the default compiler on OS X, so we use that as the<br>
>> default when running scan-build there. But mostly it's just a guess: what's<br>
>> most likely the best option on this platform? As much as we like Clang, the<br>
>> answer is probably still GCC.<br>
>><br>
>> That said, it would remove complexity to just say "we can only analyze your<br>
>> project if it builds with Clang". Ted, Anna, and I have talked about that<br>
>> idea before. But there's no urgent need to switch.<br>
>><br>
>> Jordan<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></body></html>