<div dir="ltr"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">Anna:<br></div><div class="gmail_quote"><br>On Thu, Apr 11, 2013 at 12:08 AM, Anna Zaks <span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span> wrote<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div>+<p>These macros will cover a majority of use cases; however, they still have a<div><div>+few limitations. They cannot be used inside namespaces (since they expand to</div>
<div>+contain top-level namespace references), and the data types that they define</div><div>+cannot be referenced from more than one file.</div></div><div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:19px;text-align:left;color:rgb(34,34,34)"></span></div>
<div style="text-align:left"><span style="line-height:18px"></span></div><div style="text-align:left"><span style="line-height:18px">Also, addTransition always has arguments.</span></div></div></blockquote><div><br></div>
<div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="text-align:left"><span style="line-height:19px;color:rgb(34,34,34)">----</span></div>
<div style="text-align:left">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:</div>
<div style="text-align:left"><br></div><div>Getting Started</div><div>Static Analyzer Overview</div><div>  Interaction with Checkers</div><div>Idea for a Checker</div><div>Checker Registration</div><div>Checker Skeleton</div>
<div>Custom Program States</div><div>Representing Values // With added introduction saying that we are going to store info about the values we are observing into the state..</div><div>Bug Reports</div><div>..</div><div><br>
</div></div></blockquote><div><br></div><div>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:<br><br></div><div> - Getting Started<br>
</div><div> - Static Analyzer overview   // Without the details of how states are represented<br></div><div> - Idea for a checker   // Also merge the current "AST Visitors" section into this one.<br></div><div> - Checker Registration<br>
</div><div> - Checker Skeleton<br></div><div> - 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.<br>
</div><div> - Program State Details   // Builds on the previous section; describe the specifics of ExplodedGraph/ExplodedNode, components of ProgramState.<br></div><div> - Representing Values<br></div><div> - Custom Program States<br>
</div><div> - Bug Reporting<br></div><div> - Testing<br></div><div> - Hints<br></div></div><br></div><div class="gmail_extra">All of your other comments should be addressed; updated patch attached.<br><br></div><div class="gmail_extra">
Thanks once again for reviewing this.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">--Sam<br></div><div class="gmail_extra"><br></div></div><br clear="all"><br>-- <br>===============================================================================<br>
All opinions expressed in posts from this account are entirely my own, and not<br>those of any present or former employer. Furthermore, I assert that all works<br>contributed to the Clang project (1) were developed using no equipment,<br>
supplies, facility or trade secrets of any such employer, (2) were developed<br>entirely on my own time, and (3) do not result from any work performed for any<br>such employer.<br><br>
</div>