[cfe-dev] Idea for better invoking static analysis via command line

[<Alexander G. Riccio> via cfe-dev]

>
> 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.
>

That's exactly what I'm thinking.

Somewhat related, although slightly out of date as we're actually getting
modules in C++17: "Large Code Base Change Ripple Management in C++: My
thoughts on how a new Boost C++ Library could help" (Niall Douglas)
<http://arxiv.org/pdf/1405.3323v1.pdf>


Sincerely,
Alexander Riccio
--
"Change the world or go home."
about.me/ariccio

<http://about.me/ariccio>
If left to my own devices, I will build more.
⁂

On Fri, Feb 5, 2016 at 4:30 PM, Craig, Ben <ben.craig at codeaurora.org> wrote:

> On 2/5/2016 1:49 PM, Anna Zaks via cfe-dev wrote:
>
> The new scan-build rewrite can interpose on the build system without
> interposing on CC. It produces a compilation database as output.
> http://llvm.org/viewvc/llvm-project?view=revision&revision=257533
> http://reviews.llvm.org/D9600
>
>
> 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?
>
>
> As I’ve explained in the the other thread (
> <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),
> there are reasons to discourage usage of the static analyzer directly from
> command line:
>
> "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 *user facing* clang static analysis
> tool is scan-build (see http://clang-analyzer.llvm.org). 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.
>
>
> 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.
>
> 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.
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160205/a4ef540f/attachment.html>