[PATCH] D32906: [Analyzer] Iterator Checker - Part 10: Support for iterators passed as parameter

[Balogh, Ádám via Phabricator via cfe-commits]

baloghadamsoftware added a comment.

In https://reviews.llvm.org/D32906#1257140, @NoQ wrote:

> Also i'll have a look at whether the checker is in a good shape to be enabled by default. I suspect that mismatched iterators might be very safe to enable. With all these solver and rearrangement issues, if they only cause false negatives, it's not blocking enabling the checker by default. The same applies to the debate around `find`.


Unfortunately, we are at the beginning of a long road. I will post several new patches that we already test internally. However the only checker with acceptable false-positive rate is the `invalidated-iterator` checker. The `mismatched-iterator` still has high false-positive rate for iterator-iterator mismatches. For iterator-container mismatches it is acceptable. The `iterator-range` checker also has still too many false positives.

> One thing that's most likely necessary to do before enabling the checker by default is to add a bug report visitor, so that it added notes when iterators appear for the first time or change their state. Without such notes it's usually very hard to understand warnings. Especially because we're dropping the path within inlined functions that have no interesting events, but when the iterator originates from or gets updated within such function, this information becomes crucial. The visitor might have to hop from one object to another similarly to `trackNullOrUndefValue()` (i.e., by adding more instances of itself that track objects that are being copied or moved into the object of interest at the program point that is currently being visited).

Good idea, I will try to create such a visitor. However the next step should be replacing the unaccepted part 9 by a function-summary based solution in a separate checker (std-c++-library-functions).


https://reviews.llvm.org/D32906