[cfe-dev] fix for Clang PR 8419

[Zhanyong Wan (λx.x x)]

On Sat, Nov 6, 2010 at 11:26 AM, Ted Kremenek <kremenek at apple.com> wrote:
> On Nov 4, 2010, at 5:28 PM, Zhanyong Wan (λx.x x) wrote:
>
>> Also, what do you think is the best way to ramp up on the analyzer code base?
>
> I wish there was more documentation as well.  My apologies for that.  It's something we really need to find time to do.

I'll try to help by adding comments where I need to touch the code.
In general, I think it works best if we require every patch to have
decent comments to cover the changes it introduces, as it can be a
luxury to have large chunks of time dedicated to improve the
documentation later.  Choosing descriptive identifier names (as
opposed to abbreviations like F for Factory, for example) also helps
with readability a lot.

Do you think it would be possible to enforce such a policy or
something alike?  By getting people into the habit of always
documenting the changes, the documentation will have less chance to
rot.

> I think the best way to ramp up the codebase is to pick an example problem (like the one you are exploring and dig into it).  If you are interested in bringing up support for C++ expressions, the best place to look is the visitation logic in GRExprEngine, which handles the "simulation" of individual expressions.  There's plenty of examples there of how other expressions are handled.
>
> If you are interested in writing checkers, then I'd suggest looking at the Checker and CheckerVisitor interfaces (Checker.h and CheckerVisitor.h).  Almost all the files in libChecker that are named *Checker.cpp implement this interface.  The Checker interface is designed to be minimal and simple for Checker writers, and attempts to isolate them from much of the gore of the internal analysis engine.

OK, I'll try that.  Is there a paper or design doc I can read the get
the high level idea though?

> There are some useful command line options for debugging.  For example:
>
> $ clang -cc1 -help | grep analyze | <subset that I'm pointing out>
>  -analyze-function <value>
>  -analyzer-display-progress
>  -analyzer-viz-egraph-graphviz
>
> The first allows you to specify only analyzing a specific function.  The second prints to the console what function is being analyzed.  The third generates a graphviz dot file of the ExplodedGraph.  This is extremely useful when debugging the analyzer and viewing the simulation results.
>
> Of course, viewing the CFG is also useful:
>
> $ clang -cc1 -help | grep cfg
>  -cfg-add-implicit-dtors Add C++ implicit destructors to CFGs for all analyses
>  -cfg-add-initializers   Add C++ initializers to CFGs for all analyses
>  -cfg-dump               Display Control-Flow Graphs
>  -cfg-view               View Control-Flow Graphs using GraphViz
>  -unoptimized-cfg        Generate unoptimized CFGs for all analyses
>
> -cfg-dump dumps a textual representation of the CFG to the console, and -cfg-view creates a GraphViz representation.

I think these will be very useful.  I'm willing to format and add them
to an HTML page if you can tell me where the page should be.  Thanks,

> And of course, feel free to ask lots of questions!  Myself and many others are more than welcome to help. Over time, I'd like to add some real developer documents on clang-analyzer.llvm.org.
>
>
>



-- 
Zhanyong