[cfe-commits] r162336 - /cfe/trunk/docs/analyzer/debug-checks.txt

[Anna Zaks]

On Aug 22, 2012, at 9:05 AM, Jordan Rose wrote:

> 
> On Aug 21, 2012, at 21:38 , Anna Zaks <ganna at apple.com> wrote:
> 
>> 
>> On Aug 21, 2012, at 6:03 PM, Jordan Rose wrote:
>> 
>>> +ExprInspection checks
>>> +---------------------
>>> +
>> 
>> Below, it's unclear which function you are talking about (function name is not included).  Looks like this is copy and paste from the docs.. Are comments intended to be here?
>> 
>>> +// Prints TRUE if the argument is known to have a non-zero value,
>>> +//        FALSE if the argument is known to have a zero or null value, and
>>> +//        UNKNOWN if the argument isn't sufficiently constrained on this path.
>>> +// You can use this to test other values by using expressions like "x == 5".
>>> +// Note that this functionality is currently DISABLED in inlined functions,
>>> +// since different calls to the same inlined function could provide different
>>> +// information, making it difficult to write proper -verify directives.
>>> +//
>>> +// In C, the argument can be typed as 'int' or as '_Bool'.
>>> +void clang_analyzer_eval(bool);
> 
> The function name is there, right at the bottom, in the form it should appear in a C++ test file. :-)
> 
> Since I was documenting functions, I thought it would be appropriate to write it in a header-ish style: docomuntation in the comments, followed by the function decl. Clearly the function name got lost amid all of this and it was a bad idea. I'll change it (and include an example.)
> 

I see. I think it would be better if you follow the documentation style everywhere. I was reading "ExprInspection checks Prints TRUE if the argument is known to have a non-zero value,... "

> (It's not copy-and-paste because there are no docs anywhere else.)
> 
> 
>>> +Statistics
>>> +==========
>>> +The debug.Stats checker collects various information about the analysis, such as how many blocks were reached and if the analyzer timed out. There is also an additional -analyzer-stats flag, which enables various statistics within the analyzer engine.
>>> +
>>> +(FIXME: We should probably just have the debug.Stats checker enabled when -analyzer-stats is passed. We can't do the other way around because by the time checkers are enabled it's a bit too late to start a timer.)
>> 
>> I do not think it's a good idea. analyzer-stats is supposed to be a very light weight mechanism for collecting stats. We could even use it for performance measurement. We also do not want to perform extra analyzer work when it's enabled. For example, what if we want to collect stats on BugReporter internals? Stats checker is going to produce at least one warning per function, so it will be very different from the pure execution.
> 
> Ah, I see! I didn't think of this, thanks. I'll remove the FIXME.
>