<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">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.</span><div class="" style="font-size:12.8px"></div></blockquote><div><br></div><div>That's exactly what I'm thinking.</div><div><br></div><div>Somewhat related, although slightly out of date as we're actually getting modules in C++17: <a href="http://arxiv.org/pdf/1405.3323v1.pdf">"Large Code Base Change Ripple Management in C++: My thoughts on how a new Boost C++ Library could help" (Niall Douglas)</a></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8000001907349px">Sincerely,</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Alexander Riccio</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">--</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">"Change the world or go home."</span><div style="font-size:12.8000001907349px"><a href="http://about.me/ariccio" target="_blank">about.me/ariccio</a></div><div style="font-size:12.8000001907349px"><a href="http://about.me/ariccio" target="_blank"><br></a></div><div style="font-size:12.8000001907349px">If left to my own devices, I will build more.</div><div style="font-size:12.8000001907349px">⁂</div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Feb 5, 2016 at 4:30 PM, Craig, Ben <span dir="ltr"><<a href="mailto:ben.craig@codeaurora.org" target="_blank">ben.craig@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
On 2/5/2016 1:49 PM, Anna Zaks via cfe-dev wrote:<br>
<blockquote type="cite">The new scan-build rewrite can interpose on the build
system without interposing on CC. It produces a compilation
database as output.
<div><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=257533" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=257533</a></div>
<div><a href="http://reviews.llvm.org/D9600" target="_blank">http://reviews.llvm.org/D9600</a></div>
</blockquote>
<br></span>
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?<span class=""><br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>As I’ve explained in the the other thread (<a href="http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html" target="_blank"></a><a href="http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html" target="_blank">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><br>
</div>
<div>
<div>"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>user facing</i> clang static
analysis tool is scan-build (see <a href="http://clang-analyzer.llvm.org/" rel="nofollow" link="external" style="color:rgb(85,26,139)" target="_blank">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></span>
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.<br>
<br>
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.<span class=""><br>
<pre 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>
</span></div>
</blockquote></div><br></div>