<br><br><div class="gmail_quote">On Tue Dec 23 2014 at 12:07:28 PM Gábor Horváth <<a href="mailto:xazax.hun@gmail.com">xazax.hun@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Alex!<br><br></div>I have a few more questions.<br><br></div>I did not see any checkers in clang tidy that are not ASTMatcher or PPCallbacks based. We have a checker for local variables that could be declared in a more narrow scope. It was more natural to implement that checker using RecursiveASTVisitors. Should we add a matcher for example to match function decls</div></blockquote><div><br></div><div>There is already a matcher to match function decls?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> and clas the visitor on each function body or should we add direct support for matchers that are consists of only Visitors but no matchers?<br></div></blockquote><div><br></div><div>Generally, I'd be curious what exactly you're trying to match that is more naturally expressed by writing down a RAV yourself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The report from the Static Analyzer are consumed by the AnalyzerDiagnosticConsumer which has all the information we needs. The DiagnosticBuilder however does not support a structured way to store the path sensitive information.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>To add plist output support we should be able to pass those information to DiagnosticBuilder and we would like to reuse as much code from the current PlistDiagnostics. Unfortunately the implementation of PlistDiagnostics is not part of the public API. Is it ok to make it public? What is the convention?<br></div></div></blockquote><div><br></div><div>That is indeed an interesting question - I'd start a new top-level thread discussing only this part; I know that some people had interest in seeing plist based diagnostics available more generally, so I think there will be support, but the solution must be carefully designed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think we will start to port the checkers to clang tidy and implement the plist reporting in january. Where do you expect the patches to be submitted? This mailing list, cfe-commits or the phabricator?<br></div></div></blockquote><div><br></div><div>cfe-commits is the mailing list to submit patches to, and phabricator is a way to submit patches to the mailing list :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><div><br></div>Thanks,<br>Gábor Horváth</div></div><div dir="ltr"><div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 December 2014 at 17:48, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Gábor,</div><div class="gmail_quote"><br></div><div class="gmail_quote"><span>On Fri, Dec 19, 2014 at 11:19 AM, Gábor Horváth <span dir="ltr"><<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Hi!<br><br></div>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.<br><br></div>I have some questions about the Clang Tidy though:<br></div>- 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).<br></div></div></div></div></div></blockquote><div><br></div></span><div>Clang-tidy checks use Clang's DiagnosticsEngine to report warnings which limits the structure of information passed from checks to what DiagnosticsEngine supports. This is also valid for the Static Analyzer: clang-tidy gets its results as Clang diagnostics which probably leads to some loss of information already. However, if you're fine with the information that is already passed through clang-tidy (see the ClangTidyError structure in ClangTidyDiagnosticConsumer.h)<br><br> </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>, then adding another output format should be easy. </div><span></span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>- 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.<br></div></div></div></div></blockquote><div><br></div></span><div>Currently configuration options are not passed to the Static Analyzer. If it supports this kind of configuration, it should be easy to forward options there.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>- Is there any documentation related to the specific checkers? </div></div></div></blockquote><div><br></div></span><div>Only in the class comments for each check.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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?<br></div></div></div></blockquote><div><br></div></span><div>That would be awesome. I'm happy to review patches (but expect long review times, as I'm on vacation until Jan 2).</div><div><br></div><div>Regards,</div><div>Alex</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>Thanks,<br></div>Gábor<br><div><div><div><div><br></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 18 December 2014 at 10:25, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yep, the general idea is:<br>1. if it's using ASTMatchers or PPCallbacks, make it a clang-tidy check<div>2. if it's using the CFG / being path sensitive, make it a Static Analyzer checker</div><div><br></div><div>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).</div><div><div><br><div class="gmail_quote">On Thu Dec 18 2014 at 1:40:05 AM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+Manuel<div><br></div><div>clang-tidy seems like a natural place for things that find "<span style="font-family:arial,helvetica,sans-serif;font-size:13px;line-height:14.72px">design rule violations".</span></div></div><div dir="ltr"><div><span style="font-family:arial,helvetica,sans-serif;font-size:13px;line-height:14.72px"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif;font-size:13px;line-height:14.72px">-- Sean Silva</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 4:50 AM, Gábor Horváth <span dir="ltr"><<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">

<p class="MsoNormal" style="margin-bottom:12pt;line-height:normal"><span style="font-family:arial,helvetica,sans-serif"><font>Hello everyone,</font></span></p><span style="font-family:arial,helvetica,sans-serif"><font>

</font></span><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%">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.</span></font></span></p><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%"><br></span></font></span></p><span style="font-family:arial,helvetica,sans-serif"><font>

</font></span><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%">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.</span></font></span></p><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%"><br></span></font></span></p><span style="font-family:arial,helvetica,sans-serif"><font>

</font></span><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%">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?</span></font></span></p><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font><span style="line-height:115%"><br></span></font></span></p><span style="font-family:arial,helvetica,sans-serif"><font>

</font></span><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font>Thanks,</font></span></p><span style="font-family:arial,helvetica,sans-serif"><font>

</font></span><p class="MsoNormal"><span style="font-family:arial,helvetica,sans-serif"><font>Gábor Horváth</font></span></p></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></span></div></div></div></blockquote><div> </div></div><br></div></div></div></div></blockquote></div>