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

[Craig, Ben via cfe-dev]

The judgment of "how much slower is too much slower" is pretty 
subjective, and depends on the project.  Increasing a project's build 
from 30 seconds to 5 minutes is probably too much for that project.  
Increasing a project's build from 45 minutes to 55 minutes is probably 
fine though.

Adding a flag to a build is also a much lower barrier to entry to get 
started.  There are a lot of build systems out there, and scan-build and 
compilation databases only work easily with a few of those systems.  
Adding a build flag is pretty easy on every build system that I've ever 
worked with.

If the work is done right, then the combined compile+analyze execution 
could be faster than a compile action followed by an analyze action.  If 
you're willing to give up "#ifndef __clang_analyzer__", then the AST 
from the compile can be reused by the analyzer.  Even if you aren't 
willing to give up that feature, doing a compile of a file immediately 
followed by an analysis of the same file is probably going to be faster 
than doing all the compiles then all the analyzes due to disk caching 
effects.

On 2/2/2016 10:23 AM, David Blaikie wrote:
> Another possible (not mutually exclusive) extension point to add 
> static analysis into would be through the Tooling interface and 
> compilation databases - this would allow just the analysis to be run, 
> without making it part of a build (no one would make static analysis 
> part of an interactive build, it's too slow, right? the only reason it 
> was integrated into the build with scan-build was because it was the 
> best way to discover the build commands - but the Tooling/Compilation 
> Database system allows us to separate build discovery from tool execution)
>
> On Tue, Feb 2, 2016 at 6:19 AM, Craig, Ben via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     I'm all for this idea.  There is precedent for this in other tools
>     (Visual Studio's /analyze).  I think it also greatly reduces the
>     need for build interposition via scan-build.
>
>     I would ask that you think carefully about the output format of
>     the detailed analysis for -enable-analyze-pass. If people are
>     using -enable-analyze-pass on most of their builds, then plist and
>     html reports are likely to go unread for the most part.  Consider
>     making "no detailed analysis" an option for -enable-analyze-pass
>     to help with these use cases.
>
>
>     On 1/29/2016 9:04 PM, <Alexander G. Riccio> via cfe-dev wrote:
>>     As mentioned by myself, Aaron Ballman, and Philip Reames, in a
>>     reply to "Proposal: Integrate static analysis test suites", the
>>     fact that static analysis generates a totally different set of
>>     warnings than compilation (not a superset), is surprising to some.
>>
>>     One possibility, in order to preserve the current behavior for
>>     any tools that rely on this, is to add an option to clang,
>>     something like "-enable-analyze-pass" that the user can specify
>>     to run analysis AND compilation.
>>
>>     Thoughts?
>>
>>     Sincerely,
>>     Alexander Riccio
>>     --
>>     "Change the world or go home."
>>     about.me/ariccio <http://about.me/ariccio>
>>
>>     <http://about.me/ariccio>
>>     If left to my own devices, I will build more.
>>     ⁂
>>
>>
>>     _______________________________________________
>>     cfe-dev mailing list
>>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>     -- 
>     Employee of Qualcomm Innovation Center, Inc.
>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>

-- 
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/20160202/e3ce5c8a/attachment.html>