baloghadamsoftware added a comment. In D53701#1315242 <https://reviews.llvm.org/D53701#1315242>, @NoQ wrote:
> I think it's worth a try to do a total evalCall at first, and then disable > evalCall (together with the attempt to model the iterator position) in an > incrementally growing blacklist of cases (1. iterator adaptors, 2. ....) as > we encounter problems. This essentially becomes part of the logic that > decides whether an object is an iterator. Eg., if it's more like an adaptor > than an actual iterator, let's treat it as if it's not an iterator, but > inline instead, and hope that we model the underlying iterators correctly via > evalCall. I think that only tracking the inner iterator and treating the outer iterator as a non-iterator is a nightmare from the user's perspective: all detections seem to be "internal" errors of the underlying API and thus regarded as "probably false positives". When using iterator adapters of the STL the bugs may also be filtered out by the analyzer if this option is enabled. The user must see the errors on the topmost level whenever possible to understand them. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53701/new/ https://reviews.llvm.org/D53701 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
