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.) (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
