To understand the bug report issued by the InvalidatedIterator checker it is essential to see the point where the iterator was invalidated and also to track the assignemnts of the already invalidated iterator up to its errorneous access. Since iterator invalidation is neither "done" by InvalidatedIterator checker nor by IteratorModeling but "happens" upon container modifications (modeled by ContainerModeling) the proper solution here seems to be a BugReporterVisitor instead of NoteTags.
Diff Detail
Event Timeline
You may have explained it in the summary, and I didn't get it, but why isn't putting a NoteTag in invalidateAllIteratorPositions sufficient? We could state something like All iterators associated with 'V' are invalidated. I'm not against a visitor, just playing the dumb to get on track :)
+1, that's the intended approach. I suspect we don't even need to simplify the message.
That is planned (a third patch for Container Note Tags), but does not fully solve the problem. There could be multiple operations for the same container which invalidates some iterators. Each operation creates a not tag which explains the kind of iterators invalidated (e.g. all iterators after the iterator passed in the parameter). However that does not explain which operation invalidates the particular iterator which is accessed.
Generally, I do not think the note tags should completely replace custom visitors. Instead we should take the approach which is more convenient in each case. The basic rule I can think of is the following: if the checker does something with a value when adding a new transition then we should assign a note tag to that transition. However, if something happens to the value in a transition which is done by another checker (or the core engine) then we should use a visitor to find that transition.
In this case the container modeling shrinks and extends the container and invalidates groups of iterators. However, from the point of view of an iterator the invalidation happens in another checker (ContainerModeling). Therefore I still think that a visitor is needed to mark the point where that particular iterator was invalidated. This may result in double notes like All iterators of 'V' after 'i1' are invalidated. and then the next is Iterator 'i0' is invalidated. but this is not disturbing. We already have such double notes: Assuming the condition is 'true'. then Taking 'true' branch..
However, if something happens to the value in a transition which is done by another checker (or the core engine) then
... then that checker (or the engine) adds a tag in order to explain itself, because from its point of view it
does something with a value when adding a new transition
.
This may result in double notes like All iterators of 'V' after 'i1' are invalidated. and then the next is Iterator 'i0' is invalidated.
Not if interestingness checks are performed correctly. Before emitting such note, the note tag should ask the bug report whether it's interested in all iterators being invalidated, or in how a particular iterator is invalidated. If PathSensitiveBugReport is not flexible enough to answer such questions, we should improve it.
We already have such double notes: Assuming the condition is 'true'. then Taking 'true' branch..
These are not double notes. The former describes the arbitrary state split, thus indicating that there is no concrete knowledge about the branch condition up to this point, while the latter describes the control flow in the program. Also the "Taking..." notes are displayed as arrows rather than as bubbles by GUIs that read plists, so basically everything except scan-build.