<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 2/5/2016 1:49 PM, Anna Zaks via cfe-dev wrote:<br>
    <blockquote
      cite="mid:EDD72A53-BBD0-4FDD-82E4-05C5102ED3C7@apple.com"
      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 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><a moz-do-not-send="true"
          href="http://reviews.llvm.org/D9600" class="">http://reviews.llvm.org/D9600</a></div>
    </blockquote>
    <br>
    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>
    <br>
    <blockquote
      cite="mid:EDD72A53-BBD0-4FDD-82E4-05C5102ED3C7@apple.com"
      type="cite">
      <div><br class="">
      </div>
      <div>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 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></a>),
        there are reasons to discourage usage of the static analyzer
        directly from command line:</div>
      <div><br class="">
      </div>
      <div>
        <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>
    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.<br>
    <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>
  </body>
</html>