baloghadamsoftware added a comment. Herald added a subscriber: jdoerfert. In D53701#1322255 <https://reviews.llvm.org/D53701#1322255>, @NoQ wrote:
> Well, i mean, whenever you are inlining a method, you //are// exposing > details of the "internals" of the inlined API to the user. The only > difference is whether this API itself deals with iterators. This sounds to me > as if we try not to inline iterator methods in general. Or try really hard to > prevent desynchronization between the two models. When tracking multi-level iterator structures (iterator adapters or other constructs e.g. a leaf-iterator in a general tree) we mainly want to track the topmost level, but it is inaccurate without inlining their methods. We need the to track the real control flow. However, when reporting a bug we want to report it at the topmost level since the erroneous code is most probably the top-level code, not the API. That way we do not directly expose the layers below the API to the user. That is the reason that we have to handle all structures which behave as iterators as iterators, even if they contain iterators themselves. Since error-checking happens in the `checkPre...()` hooks, bugs are automatically catched at the topmost level. > Ok, how about an eager state split for now? Do you mean that upon iterator comparison I do not record the comparison and later retrieve it in the branches with concrete results but I do the state-split myself in `checkPostCall()`? 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
