<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 4:26 AM, David Chisnall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 4 Feb 2016, at 23:52, via cfe-dev <Alexander G. Riccio> wrote:<br class=""><blockquote type="cite" class=""><br class="">Adding a flag to a build is also a much lower barrier to entry to get<br class="">started. <br class=""><br class="">Example #1: I don't have Perl. Not many machines have Perl. That makes scan-build problematic.<br class=""><br class="">"Not many" is relative to Python. Python ate the world.<br class=""><br class=""></blockquote><br class="">Neither Python nor Perl is in the FreeBSD base system. Additionally, we can very easily add flags to our build system, but we can’t reliably run it to completion with something that interposes on CC, because various things define a different CC for different things.<br class=""><br class=""></div></div></blockquote><div><br class=""></div>The new scan-build rewrite can interpose on the build system without interposing on CC. It produces a compilation database as output.</div><div><a 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 href="http://reviews.llvm.org/D9600" class="">http://reviews.llvm.org/D9600</a></div><div><br class=""></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" class="">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 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 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 class=""><br class=""></div><div class="">I agree that the best user experience is to report all warnings in one place, while still differentiating which warning was reported by which tool. It would be awesome if the results from all bug finding tools such as the clang static analyzer, the compiler, and clang-tidy would be reported through the same interface.</div><div class=""><br class=""></div><div class="">The CodeChecker team is working on a solution for that and I hope we can incorporate their technology in LLVM/clang.</div><div class="">"</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Having a well-documented set of flags for static analysis would also make it much easier to integrate with systems such as CMake. I’d love to be able to kick off a build in our CI systems for things that use CMake that would do the build and analysis in parallel, with neither blocking the other, and be able to start running tests once the build has finished, even if the static analysis is still ongoing. All of the dependency metadata for doing this exists in our build system, none of it is easily exploited by scan-build (for things that use CMake, all of it could be extracted from the generated JSON, but it would be nicer to just have some separate targets that ninja knew were independent top-level things).<br class=""></div></div></blockquote><div><br class=""></div><div>As others mentioned in that thread, even though we do not encourage using 'clang —analyze’, the options are documented in clang help, so you could integrate it into your build system. The main issues would be hard to understand results and possibility that the integration is going to break in the future.</div><div><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">David<br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></div></blockquote></div><br class=""></body></html>