[PATCH] Add a check to flag the usage of C-style casts (Google Style).

[Alp Toker]

On 25/06/2014 21:16, Alexander Kornienko wrote:
> On Wed, Jun 25, 2014 at 7:17 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 25/06/2014 14:06, Alexander Kornienko wrote:
>
>         On Wed, Jun 25, 2014 at 10:48 AM, Alp Toker <alp at nuanti.com
>         <mailto:alp at nuanti.com> <mailto:alp at nuanti.com
>         <mailto:alp at nuanti.com>>> wrote:
>
>             How about just using -Wold-style-cast?
>
>
>         I thought, it was agreed upon, that the -Wold-style-cast
>         warning isn't going to suggest automatic fixes:
>         http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/094121.html.
>         However, this check is going to.
>
>         Any other concerns?
>
>
>     Hmm, if this is identical to -Wold-style-cast why is it going into
>     clang-tidy/google/?
>
>     There doesn't seem to be anything Google-specific at all here, any
>     more than the equivalent compiler flag in clang is Nuanti-specific.
>
>
> Currently, we're trying to organize the checks by coding style to make 
> it easy to select all checks from a certain style (using 
> -checks=-*,google-* or -checks=-*,llvm-*). And from the two coding 
> styles we are currently planning to support, only one specifically has 
> the rule to avoid C-style casts. If the check didn't implement a rule 
> of one of this styles, it would go misc/.

Right, I've looked into this and we'd be OK to contribute our own vendor 
module to follow the current policy in clang-tools-extra, I'll submit 
this as a new patch.

> We know that this system is sub-optimal, as categorization of the 
> checks by style doesn't work well when checks can be shared between 
> styles. A better approach could be to have checks arranged separately 
> by some property (e.g. some characteristic of the issue they address - 
> readability/performance/compatibility/bug-prone coding patterns), and 
> the styles being just lists of checks with specific configurations and 
> meta-data (e.g. links to specific style guide rules).

The frontend diagnostic warning group hierarchy would cover this use 
case perfectly. I've been making good progress with the diagnostics 
engine refactor to support external use, with the last remaining 
layering issues related to lexer usage for token measurement. 
clang-tools-extra is already dependent on Lex so I think we'll be ready 
to support this use case real early post 3.5.

Alp.


>
> We're going to do this kind of rearrangement, but it will be done 
> independently from this patch.



-- 
http://www.nuanti.com
the browser experts