
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 27, 2013, at 14:56 , Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com">rizsotto.mailinglist@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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></blockquote><div><br></div>Hi, Laszlo. Thanks for doing this.<div><br></div><br><blockquote type="cite">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></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite">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></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite">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></blockquote></div><br><div>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 <i>old</i> 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 <i>build,</i> which could cause downstream issues and keep us from analyzing <i>every</i> file after this one.</div><div><br></div><div>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.</div><div><br></div><div><i>That</i> said, it <i>would</i> 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.</div><div><br></div><div>Jordan</div></body></html>