On 25/06/2014 21:16, Alexander Kornienko wrote:
On Wed, Jun 25, 2014 at 7:17 PM, Alp Toker <[email protected]
<mailto:[email protected]>> wrote:
On 25/06/2014 14:06, Alexander Kornienko wrote:
On Wed, Jun 25, 2014 at 10:48 AM, Alp Toker <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
