[cfe-dev] Open sourcing a batch of checkers

[Gábor Horváth]

Hi!

I started to investigate how Clang Tidy works, and I find it very
promising. We are likely to convert our ASTMatcher/PPCallback/ASTVisitor
checks to clang tidy checkers and submit patches. We will submit our Static
Analyzer checkers as well. Not all of our checkers are style based, but we
will add fix-its where appropriate when doing the conversions.

I have some questions about the Clang Tidy though:
- Is it possible to report issues in plist output format? Right now we are
consuming the plist output of the Static Analyzer. Once we converted our
codebase to use Clang Tidy we would like to continue to parse the plist
output. If it is not possible now, we also would like to develop and
contribute the plist reporting to Clang Tidy (in case you find it a worthy
addition).
- As far as I can see, one can specify key value pairs as configuration
options for checkers. Can these values passed to Static Analyzer checkers
as well? If not, we also would like to add this capability and contribute
it if you find it useful enough.
- Is there any documentation related to the specific checkers? What we do
right now: there is a markdown file next to each of our checker
implementation files and we have a build option to generate a HTML
documentation that contains the user documentation of each checker (when to
use, guidelines to fix, code examples, limitations, rationales etc). I
think it might be useful to have similar system in clang tidy. What do you
think?

Thanks,
Gábor


On 18 December 2014 at 10:25, 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).
>
> 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/20141219/50249315/attachment.html>