The change enables tracking statistics across revisions.
Details
Diff Detail
Event Timeline
lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp | ||
---|---|---|
189 | Raw pointers are annoying, and it made no sense to me that the timer is statistic, yet is always initialized in constructor. | |
205 | Having a group gives nicer statistics output, which explicitly states that this is an analyzer timer (as opposed to timer.misc.time) | |
214 | I hate doing stuff in destructors, so I would much rather set PrintOnExit back to true, and remove the destructor altogether, but I was worried of making this CL too large. | |
572 | Moving reset down is required to make sure the timer and extra statistics are available. Again, I would have liked to explicitly call flush or similar instead of relying on destructor, but it seemed out of place in this CL. |
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
492 | I'm split between just adding it in an extra "statistics" field and having it as a comment. I would prefer the former, but I was afraid some random parser somewhere might choke. |
Why not turn this on by default when we turn on reporting statistics?
Having a test for the plist output would be nice.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
492 | I suspect that any "normal" parser (libplist of some sort) would accept both and any "dumb" parser (that parses the plist line-by-line with regexps and expect exact these lines) would choke on any of those with roughly the same probability. So i'm in favor of adding a field - at least those are being added more often, and dumb parser maintainers might be used to it by now. |
So are these present only on translation units that actually caused bug reports to appear?
Having a test for the plist output would be nice.
I suspect such test would be super fragile. Every time we change any modeling, many of the stats may change.
Why not turn this on by default when we turn on reporting statistics?
One issue is that LLVM timers can only be printed once (yeah, I know...) and serializing those numbers would "eat" the output, and then timers would not be displayed with -analyzer-stats.
But I guess I might as well fix the underlying problem.
Having a test for the plist output would be nice.
The problem is tests can be run on release configuration, which can not generate statistics at all. How could we check for that in a sensible way?
Would // REQUIRES: asserts be relevant? I don't think there's any sort of // REQUIRES: debug, what exactly is needed here?
(https://llvm.org/docs/TestingGuide.html#constraining-test-execution)
So if https://reviews.llvm.org/D43136 goes through, we could change this to print on -analyzer-stats or even always dumping statistics when an assertion-enabled build of clang is used.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
493–496 | Would this actually be a valid plist file? Maybe we should surround statistics with <string>...</string>? |
Yep, so i guess printing statistics as plist key-value pairs would be tricky. LGTM!~
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
493–496 | Oh, yay, nice. It seems that i didn't even look at the test. |
I'm split between just adding it in an extra "statistics" field and having it as a comment. I would prefer the former, but I was afraid some random parser somewhere might choke.