[cfe-dev] [Patch] Update to Checker Development Manual

[Sam Handler]

Anna:

On Thu, Apr 11, 2013 at 12:08 AM, Anna Zaks <ganna at apple.com> wrote
>
>
> +<p>These macros will cover a majority of use cases; however, they still
> have a
> +few limitations. They cannot be used inside namespaces (since they expand
> to
> +contain top-level namespace references), and the data types that they
> define
> +cannot be referenced from more than one file.
>
> I would just say "Note that the macros cannot be used inside namespaces
> (since they expand to contain top-level namespace references)." The macros
> can be referred to from multiple files if they are defined in a header that
> is included from all of them. It's just that each checker is usually
> contained in a single file.
>

The comment above REGISTER_TRAIT_WITH_PROGRAMSTATE says that should not be
used "for traits that must be accessible from more than one translation
unit." I assume this is the case because the GDMIndex function that is
generated is returning the address of a static variable, which would be
different in different translation units.

Also, addTransition always has arguments.
>

I've changed it to suggest CheckerContext::getState instead of
addTransition in cases where there are no state updates and the updated
state (as returned by addTransition) in cases where there are state updates.


> ----
> I think the current flow does not make much sense anymore. For example,
> "Idea for a Checker" should go before the sections you've added. I think
> the following order would be best:
>
> Getting Started
> Static Analyzer Overview
>   Interaction with Checkers
> Idea for a Checker
> Checker Registration
> Checker Skeleton
> Custom Program States
> Representing Values // With added introduction saying that we are going to
> store info about the values we are observing into the state..
> Bug Reports
> ..
>
>
I was also wondering about the order, but reordering the document seemed a
bit too ambitious for a first step. The order I was thinking of was:

 - Getting Started
 - Static Analyzer overview   // Without the details of how states are
represented
 - Idea for a checker   // Also merge the current "AST Visitors" section
into this one.
 - Checker Registration
 - Checker Skeleton
 - Program State Example   // Not yet written. An example showing how the
ExplodedGraph is constructed for a simple function, including both value
constraints and custom program state, without describing the specific data
structures used.
 - Program State Details   // Builds on the previous section; describe the
specifics of ExplodedGraph/ExplodedNode, components of ProgramState.
 - Representing Values
 - Custom Program States
 - Bug Reporting
 - Testing
 - Hints

All of your other comments should be addressed; updated patch attached.

Thanks once again for reviewing this.

--Sam



-- 
===============================================================================
All opinions expressed in posts from this account are entirely my own, and
not
those of any present or former employer. Furthermore, I assert that all
works
contributed to the Clang project (1) were developed using no equipment,
supplies, facility or trade secrets of any such employer, (2) were developed
entirely on my own time, and (3) do not result from any work performed for
any
such employer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130414/94d6cc38/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: checker_dev_manual.diff
Type: application/octet-stream
Size: 17088 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130414/94d6cc38/attachment.obj>