<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Piotr,</div><div><br></div><div>I think that it would be great to add your checks to clang-tidy.</div><div>I've had a quick look at colobot-lint and, IMO, it would be nice to add some other checks, e.g. NakedNew, NakedDelete, ImplicitBoolCast may be of interest.</div><div><br></div><div>BTW, does your InconsistentDeclarationParameterNameRule handles unused parameters (i.e. those that have names in the declaration, but are marked /*unused*/ or something along these lines in the definition)?</div><div><br></div><div>Regards,</div><div>Marek Kurdej</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">---------- Wiadomość przekazana dalej ----------<br>From: Piotr Dziwinski via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>Cc: <br>Date: Thu, 27 Aug 2015 18:53:30 +0200<br>Subject: [cfe-dev] [clang-tidy] Some possible contributions<br>Hello,<br>
<br>
I am the author of a static analysis tool using Clang's LibTooling which I wrote for the open-source Colobot project (<a href="https://github.com/colobot/colobot" rel="noreferrer" target="_blank">https://github.com/colobot/colobot</a>). This tool, which I named colobot-lint (<a href="https://github.com/colobot/colobot-lint" rel="noreferrer" target="_blank">https://github.com/colobot/colobot-lint</a>), is written using a framework loosely based on the code of clang-tidy.<br>
<br>
Now that my little project has matured enough, I think I may contribute some of its code back to clang-tidy. However, before I create patches and send them to cfe-commits, I'd like to hear some discussion on whether you think my code is generic enough and useful enough to be included in clang-tidy.<br>
<br>
For now I only propose the following two patches based on what I think is the most generic of what I wrote. My tool does a lot more, but I won't bore you with details here (if you're curious, it's documented in README files).<br>
<br>
<br>
Patch proposal #1: add check for inconsistent parameter names in function declarations<br>
This will check for instances of function (re-)declarations which differ in parameter names. For example: void foo(int a, int b, int c); in header file and void foo(int d, int e, int f) { /*...*/ } in code module file.<br>
This check may be useful to enforce consistency in a large project, keeping declaration and definition always in sync. In extreme case, I think it may even prevent some class of bugs, as declaration may not get updated during refactoring and then a person writing code against the outdated interface, may get the wrong idea of what parameters to pass to the function.<br>
<br>
<br>
Patch proposal #2: add check for instances of old C-style functions<br>
This will check for instances of legacy functions which use old C-style convention of declaring all parameters at the beginning of the function:<br>
void foo()<br>
{<br>
    int a, i;<br>
    /* and later, after many lines in between, there is first use of declared variables: */<br>
    a = bar();<br>
    for (i = 0; i < 10; ++i) { /*...*/ }<br>
}<br>
It may be useful for people who have to maintain old codebases and want to find instances of such functions to refactor them to "modern" C++ style, declaring variables in the place where they are needed. This in fact is exactly what we're doing in Colobot project and I imagine there are other projects like that.<br>
<br>
<br>
Please let me know if you think I should proceed with submitting these patches. I can also prepare other patches if you think some other parts of my code would be useful.<br>
<br>
Best regards,<br>
Piotr Dziwinski<br></blockquote></div></div></div>