[cfe-commits] Patch to do static analysis with range sets

[Ted Kremenek]

On Feb 8, 2009, at 6:57 AM, Ben Laurie wrote:

>> Without making comments on the rest of the patch (which looks  
>> similar to the
>> other parts), I think there just needs to be a high-level comment  
>> of what is
>> the algorithmic model for the constraints, how they are resolved,  
>> what is
>> represented, etc.  Right now it is difficult for me to evaluate the  
>> approach
>> itself since I don't really understand the algorithm.  Also, I  
>> think that
>> the implementation itself should come in a straightforward manner  
>> once a few
>> key methods (e.g., "CouldBeEQ") get fleshed out.  I'm more than  
>> happy to
>> help with this process.
>
> How would that work in practice? Without switching to mercurial,  
> that is?
>
> Anyway, will work on a new version of the patch.

I personally love distributed version control systems, and maybe one  
day LLVM will use one (a prerequisite being that someone volunteers to  
set up all the needed infrastructure).

That said, I don't think that's necessary for collaboration.  LLVM  
(and clang) developers through a very rapid prototyping model.  We  
prefer incremental patches that stub out an implementation, and have  
pieces of functionality gradually working over time.  It has worked  
very well for bringing up countless features in both LLVM and Clang  
involving many contributors with disparate ideas.

For contributing to the static analyzer, I've tried to make the design  
modular so that pieces can be swapped in and out.  A new  
RangeConstraintManager (or whatever is called) can easily be slotted  
in as a separate .cpp file that gets implemented in pieces.   
Subclasses of ConstraintManager implement a specific interface, and  
when prototyping a new ConstraintManager one can just assert on cases  
that are currently not supported (this is a great way to test an  
implementation as it evolves).  As pieces get added, e.g., to support  
'>' or '<' constraints, test cases can get added to the test suite, etc.

Mechanically, this process would consist of incremental patch  
submission and review.  After a contributor has provided a few  
significant patches to the tree they are then granted direct commit  
access.  This access is initially commit-on-approval (i.e., patches  
must be reviewed) and then as the patches reach a point where the  
contributor clearly understands the coding standards, the impact of  
their patches, etc., patches are then reviewed after they are  
committed.  For significant patches that may change many things,  
you'll notice that even regular contributors frequently send out their  
patches for review, particular if their is a question regarding its  
design or implementation.