<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 5, 2016, at 1:30 PM, Craig, Ben <<a href="mailto:ben.craig@codeaurora.org" class="">ben.craig@codeaurora.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
On 2/5/2016 1:49 PM, Anna Zaks via cfe-dev wrote:<br class="">
<blockquote cite="mid:EDD72A53-BBD0-4FDD-82E4-05C5102ED3C7@apple.com" type="cite" class="">The new scan-build rewrite can interpose on the build
system without interposing on CC. It produces a compilation
database as output.
<div class=""><a moz-do-not-send="true" href="http://llvm.org/viewvc/llvm-project?view=revision&revision=257533" class="">http://llvm.org/viewvc/llvm-project?view=revision&revision=257533</a></div>
<div class=""><a moz-do-not-send="true" href="http://reviews.llvm.org/D9600" class="">http://reviews.llvm.org/D9600</a></div>
</blockquote>
<br class="">
Do you foresee the python version of scan-build being suitable for
use in XCode? Would you expect the python version of scan-build to
be suitable for a Visual Studio build that uses the clang front end?<br class=""></div></div></blockquote><div><br class=""></div>The Xcode build system (xcodebuild) directly integrates the static analyzer. It knowingly relies on the “implementation detail” and we'll be ready to update our integration if WPA is added. The reason for this is that we are not afraid to break Xcode, which we control. Xcode IDE directly consumes the plist files. The new scan-build will have support for xcodebuild.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
<blockquote cite="mid:EDD72A53-BBD0-4FDD-82E4-05C5102ED3C7@apple.com" type="cite" class="">
<div class=""><br class="">
</div>
<div class="">As I’ve explained in the the other thread (<a moz-do-not-send="true" href="http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html" class=""></a><a class="moz-txt-link-freetext" href="http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html">http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html</a>),
there are reasons to discourage usage of the static analyzer
directly from command line:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">"Most importantly, end users should never invoke
the analyzer by calling “clang —analyze” since “clang
—analyze” is an implementation detail of the static analyzer.
The only advertised <i class="">user facing</i> clang static
analysis tool is scan-build (see <a moz-do-not-send="true" href="http://clang-analyzer.llvm.org/" class="" target="_top" rel="nofollow" link="external" style="color:
rgb(85, 26, 139);">http://clang-analyzer.llvm.org</a>). Here
are some reasons for that. For one, it is almost impossible to
understand why the static analyzer warns without examining the
error paths. Second, the analyzer could be extended to perform
whole project analysis in the future and "clang —analyze"
works with a single TU at a time.</div>
</div>
</blockquote>
<br class="">
Yes, --analyze is currently an implementation detail. I would
prefer that not be the case. It is my opinion that --analyze (or
something like it) should be the supported user interface, and that
scan-build should be a client of that interface. The same HTML
and/or plist (or neither!) could be generated from the command
line. With the current state of support, we have high profile
customers (XCode) of static analysis using unsupported flags.</div></div></blockquote></div><div><br class=""></div><div>Ok. I agree that it would be beneficial to officially support 'clang —analyze’ as an option to <b class="">analyze a single translation unit</b>. We’ve essentially been doing that for years and many do rely on it whether we want it on not. I think the default output should be either plist or some other format that preserves the same level of information (JASON?) because all the other formats are less precise.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
As for post-processing and whole program analysis, I think the best
user experience here would be to embed some meta-data in .o files,
and let the clang-driver orchestrate the post-processing / WPA
during the linking step. This closely parallels how
link-time-optimization works, and still makes for a work-flow with a
low barrier to entry. Just put --enable-analyze-pass in the compile
line and the link line, and you can still get the nice index.html
and whole program analysis without any extra tools.<br class=""></div></div></blockquote><div><br class=""></div><div>Performing WPA at the link step is not necessarily the right design option and I would not want to commit to it before the feature is designed. Moreover, most build systems call the linker directly, so the driver option might not buy us much anyway. This means that users may need to revisit their integration once WPA is added (given that they'd want to take advantage of that feature).</div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><pre class="moz-signature" cols="72"><br class=""></pre><pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</div>
</div></blockquote></div><br class=""></body></html>