On Mar 20, 2012, at 4:51 PM, Jordan Rose <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
