[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-commits
Subject:    [PATCH] D29151: [clang-tidy] Add misc-invalidated-iterators check.
From:       Piotr Padlewski via Phabricator via cfe-commits <cfe-commits () lists ! llvm ! org>
Date:       2017-01-31 23:26:02
Message-ID: 54915d5f92ef3128c885630a243f4080 () localhost ! localdomain
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]