On Aug 22, 2012, at 9:05 AM, Jordan Rose wrote: > > On Aug 21, 2012, at 21:38 , Anna Zaks <[email protected]> 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. > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
