Prazek added a comment. In https://reviews.llvm.org/D29151#658484, @zaks.anna wrote:
> 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.) I think we need some sort of clear guidelines on where what functionality should be added. Even right now there are clang-tidy checks that finds subset of alpha checks, but probably having lower false positive rate. The other example is Use after move, that is doing similar thing as uninitialized values analysis in clang. Repository: rL LLVM https://reviews.llvm.org/D29151 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
