[Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Niels de Vos]

On Tue, May 26, 2015 at 11:00:25PM +0530, Atin Mukherjee wrote:
> On 26 May 2015 17:30, "Prasanna Kalever" <pkalever at redhat.com> wrote:
> >
> > Hi gluster team,
> >
> > Proposal:
> >
> > Using Clang static analyzer tool for gluster project
> >
> >
> > About Clang:
> >
> > From a very high level view, Clang has two features
> >
> > 1. Clang as a compiler
> > 2. Clang as a code analyzer
> >
> > The Idea hear is to use second point i.e Clang as code analyzer and still
> gcc
> > will be our default compiler.
> >
> > The Clang Static Analyzer is a source code analysis tool that finds bugs
> in C,
> > C++, and Objective-C programs. Given the exact same code base,
> clang-analyzer
> > reported ~70 potential issues. clang is an awesome and free tool.
> >
> > The reports from clang-analyzer are in HTML and there's a single file for
> each
> > issue and it generates a nice looking source code with embedded comments
> about
> > which flow that was followed all the way down to the problem.
> >
> >
> > Why Clang-Analyzer: (Advantages)
> >
> >  1. Since its is an open source tool:
> >
> >   * Available to all the developers
> >   * Easy Access, we can run the tool while we compile the code (say $
> scan-build make)
> >   * No restrictions on Number of Runs per week/day/hour/min ..
> >   * Defects are Identified before submitting a patch, thus very less
> chance of
> >     defect injection into project
> >
> >  2. The Html view of clang is very impressive with all the source code
> including
> >     comments of clang-analyzer, which lead to defect line number directly
> .
> >
> >
> >
> > I have attached a sample clang results for geo-replication module run on
> latest
> > 3.7+ glusterfs code, please find them above.
> >
> >
> > Thanks for your time.
> On a relative note, I feel we should try to integrate any of these static
> analyzer as part of our checkpatch.pl and compare the pre and post report
> and proceed if the change doesn't introduce any new defects. Thoughts?

That sounds more like a test we can run in Jenkins. Having this check in
checkpatch.pl might be difficult because that should be able to run on
any OS/distribution we support. When we move the test to Jenkins, we can
run it on the regression test slaves and have them post -1 verified in
case of issues.

Are there tools to do the pre/post result comparing? I have recently
setup a test environment for Jenkins jobs and am happy to give you (or
any one else) access to it for testing (sorry, my setup is on the Red
Hat internal network only).

Niels