[cfe-commits] Adding interesting symbols during path diagnostic generation
Ted Kremenek
kremenek at apple.com
Tue Mar 20 22:45:27 PDT 2012
On Mar 20, 2012, at 4:51 PM, Jordan Rose <jediknil at belkadan.com> wrote:
>> This seems to implement the first suggestion by Ted, where we attempt to regenerate a single PathDiagnosticPiece, not the whole path, which would not work for state-full visitors. Am I missing something?
>
> Oh, I wasn't sure that was the final decision. It makes things a little easier on the checker writer to worry about visiting the same nodes twice, but MallocChecker is certainly still stateful.
I think it is fine to keep it stateful. It's actually a great feature. If we can clone all the *initial* BugReporterVisitors at the very beginning, before we generate the PathDiagnostic, we always have something to roll back to if we decide to start over and generate the path again with a set of new interesting symbols.
For example, we could make a BugReporterVisitorsImpl class, which is a template, which has a "clone()" virtual method, e.g.:
BugReporterVisitor *clone() {
return new DERIVED(this);
}
then specific visitors derive from this class, e.g.:
class MyVisitor : public BugReporterVisitorImpl<MyVisitor> { ... };
We could clone all the visitors up front when generating a path, and always roll back to the original ones when generating a PathDiagnostic on the second, third, fourth passes, etc.
> Still, if we really don't care about performance during diagnostic generation...
In all likelihood, we will only regenerate an entire path a handful of times. This is dwarfed by the amount of work to do the analysis in the first place to find the bug. We also aren't repeating the logic to find the shortest path; just the logic to generate the events and control-flow arrows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120320/43e7bf64/attachment.html>
More information about the cfe-commits
mailing list