[PATCH] D29151: [clang-tidy] Add misc-invalidated-iterators check.

[Anna Zaks via Phabricator via cfe-commits]

zaks.anna added a comment.

The static analyzer is definitely the place to go for bug detection that requires path sensitivity. It's also reasonably good for anything that needs flow-sensitivity. Although, most flow-sensitive analysis (such as liveness) now live in lib/Analysis/, which is used by both Sema and the Clang Static Analyzer. Both path-sensitive and flow-sensitive analysis are based on clang's CFG. I do not know of clang-tidy uses CFG or lib/Analysis/.

Here are the wikipedia definitions of sensitivity I am referring to:
//- A flow-sensitive analysis takes into account the order of statements in a program. For example, a flow-insensitive pointer alias analysis may determine "variables x and y may refer to the same location", while a flow-sensitive analysis may determine "after statement 20, variables x and y may refer to the same location".

- A path-sensitive analysis computes different pieces of analysis information dependent on the predicates at conditional branch instructions. For instance, if a branch contains a condition x>0, then on the fall-through path, the analysis would assume that x<=0 and on the target of the branch it would assume that indeed x>0 holds. //

There is work underway in the analyzer for adding IteratorPastEnd checker. The first commit was rather large and has been reviewed here https://reviews.llvm.org/D25660. That checker is very close to be moved out of alpha. Moving it out of alpha is pending evaluation on real codebases to ensure that the false positive rates are low and enhancements to error reporting.

> Other problem is that it would be probably a part 
>  of one of the alpha checks, that are not developed and I don't know if they will ever be fully supported.

There seems to be a misconception about what the alpha checkers are. All checkers start in alpha package to allow in-tree incremental development. Once the checkers are complete, they should move out of alpha. The criteria is that the code should pass the review, the checker needs to have low false positive rates, finally, the error reports should be of good quality (some checks greatly benefit from extra path hints that can be implemented with a visitor). These are motivated by providing a good user experience to end users. (We do have several checkers that are "stuck in alpha". A lot of them are abandoned experiments that just need to be deleted; others could probably be made production quality with some extra effort.)


Repository:
  rL LLVM

https://reviews.llvm.org/D29151