NoQ added a comment. So we have an `ExplodedGraph`, in that there's an `ExplodedNode` against which the report is being thrown, we have a bunch of `BugReporterVisitor`s that walk from that node to the root of the graph and mark places they find interesting with `PathDiagnosticPiece`s of different kinds, and `PathDiagnosticConsumer`s (such as Plist or Html) that look at the vector of pieces and display it to the user.
It sounds solid (even if a bit over-engineered) to implement your counterexample generator as a set of: 1. new class of `PathDiagnosticPiece`s that holds information that you need about a single line of code. Like, a while ago i was adding blue bubbles to scan-build (https://reviews.llvm.org/D24278), you might use this as an example on how to add a new class of diagnostic pieces. 2. a new `BugReporterVisitor` attached to all reports that puts such piece on every line of code. You already have it, but now it'd return the piece instead of printing stuff to console. Now that i think of it, the best place to add a visitor to all reports would be `GRBugReporter::generatePathDiagnostic()` - this is where other non-checker-specific visitors are added. 3. a new `PathDiagnosticConsumer` that would transform your new pieces into report files or however you want to present the results. I guess you could follow the examples of the existing consumers here; i didn't hack much on those, but there doesn't seem to be much boilerplate here. Most of the complicated processing, if any, goes here, the visitor can at best provide a set of pieces in chronological order, he cannot rearrange them anyhow but the consumer can. https://reviews.llvm.org/D40809 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
