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

[Anna Zaks via cfe-dev]

> On Feb 5, 2016, at 1: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://llvm.org/viewvc/llvm-project?view=revision&revision=257533>
>> http://reviews.llvm.org/D9600 <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?

The Xcode build system (xcodebuild) directly integrates the static analyzer. It knowingly relies on the “implementation detail” and we'll be ready to update our integration if WPA is added. The reason for this is that we are not afraid to break Xcode, which we control. Xcode IDE directly consumes the plist files. The new scan-build will have support for xcodebuild.

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


Ok. I agree that it would be beneficial to officially support 'clang —analyze’ as an option to analyze a single translation unit. We’ve essentially been doing that for years and many do rely on it whether we want it on not. I think the default output should be either plist or some other format that preserves the same level of information (JASON?) because all the other formats are less precise.

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

Performing WPA at the link step is not necessarily the right design option and I would not want to commit to it before the feature is designed. Moreover, most build systems call the linker directly, so the driver option might not buy us much anyway. This means that users may need to revisit their integration once WPA is added (given that they'd want to take advantage of that feature).
> 
> -- 
> 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/1cd46016/attachment.html>