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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
