[cfe-dev] Open sourcing a batch of checkers

C Bergström cbergstrom at pathscale.com
Wed Dec 17 18:24:25 PST 2014


On Wed, Dec 17, 2014 at 7:50 PM, Gábor Horváth <xazax.hun at gmail.com> wrote:
>
> Hello everyone,
>
> I am an intern at a company where we developed several checkers based on
> the clang infrastructure. We have about 30 checkers that are either C++
> core language or STL related. We would like to contribute some of these
> checkers (together with the documentation and the test cases). The ones
> that are well tested and have good false positive rates.
>
>
> Most of the checkers were originally developed find certain design rule
> violations. One example of a design rule at this company is: „The emptiness
> of a container should be checked using the empty method instead of the size
> method. It is not guaranteed that size is a constant-time function, and it
> is generally more efficient and also shows clearer intent to use empty.
> Furthermore some containers may implement the empty method but not
> implement the size method. Using empty whenever possible makes it easier to
> switch to another container in the future.” We realized that, maybe such
> checkers could be useful for the clang community as well.
>
>
> Our tool right now is a clang plugin that runs custom frontend actions on
> the analyzed source code. The reason is that, some of the checkers are only
> consist of ASTMatchers, some of them using RecursiveASTVisitors, some of
> them are clang Static Analyzer checkers. We are wondering what would be the
> desired way to contribute those checkers back. Should we focus on migrating
> them to clang-tidy? Should we focus on transforming them to Static Analyzer
> checkers?
>

This sounds very interesting. For a start it may be easier if some of the
source code and tests in question are available to take a look at. Is it on
github?

In general and not specific to your request for feedback - I'd say keep
patience in mind. The community tends to review code from "friends" at a
much higher priority. Don't be discouraged if you don't get an immediate
reply from one of the main contributors. Holidays, internal release
deadlines and many things could in theory contribute to delayed feedback or
eventual reviews. (OpenMP work is a good example of persistence)

Thanks and good luck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141218/74241f84/attachment.html>


More information about the cfe-dev mailing list