[cfe-dev] Open sourcing a batch of checkers

[Alexander Kornienko]

On Thu, Dec 18, 2014 at 10:25 AM, Manuel Klimek <klimek at google.com> wrote:
>
> Yep, the general idea is:
> 1. if it's using ASTMatchers or PPCallbacks, make it a clang-tidy check
> 2. if it's using the CFG / being path sensitive, make it a Static Analyzer
> checker
>
> Note that static analyzer checkers are integrated in clang-tidy
> automatically - usually style rule stuff is much easier expressed in
> clang-tidy though (and I don't think static analyzer checks are integrated
> well with fix-its (but I'm not sure), and style violations usually have
> easy fix-its).
>

+1
If your checks don't yet suggest fixes, I'd urge you to implement fixes at
least for all checks, where it's straightforward. Style warnings are close
to useless without fix-its, because not many people like spending time to
fix manually style nits in their code.

If you have any questions re: porting the checks to clang-tidy, I'll be
happy to help.

-- Alex


>
> On Thu Dec 18 2014 at 1:40:05 AM Sean Silva <chisophugis at gmail.com> wrote:
>
>> +Manuel
>>
>> clang-tidy seems like a natural place for things that find "design rule
>> violations".
>>
>> -- Sean Silva
>>
>> On Wed, Dec 17, 2014 at 4:50 AM, 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?
>>>
>>>
>>> Thanks,
>>>
>>> Gábor Horváth
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141218/9ed72619/attachment.html>