[cfe-dev] clang-tidy, clang-modernize, and remove-cstr-calls

[Philip Reames]

On 01/30/2015 01:25 PM, Mario Lang wrote:
> Richard <legalize at xmission.com> writes:
>
>> Should remove-cstr-calls be migrated to a clang-tidy check?
> I've thought the same in the past, and I think yes.  It would fit clang-tidy.
>
>> What about clang-modernize?  Are the transformations there considered
>> to be of the lint variety?  Should those transformations be migrated
>> to clang-tidy as well?
> I think clang-modernize should stay separate, as it doesn't strictly
> search for programming errors of inefficiencies.  It is really a source-code upgrade
> tool, something you run once you've decided to switch your standard
> level.  One might argue that clang-modernize could be run as part of
> clang-tidy, if LangOpts specified CPlusPlus11, but I am not convinced.
> OTOH, the check-enabling syntax of clang-tidy makes it rather easy to
> run modernize as part of it... "clang-tidy -fix -checks=modernize"
> wouldn't be particularily hard to type.  But keep in mind that clang-modernize seems
> to be able to run without a compilation database, which doesn't apply to
> clang-tidy.
Specifically with regards to:
"[clang-modernize] is really a source-code upgrade tool, something you 
run once you've decided to switch your standard level. "

I really don't think this is true in practice.  As a good example, take 
a look at all the changes landing in LLVM for range-based for loops.  
Some of them (most even) are updating old code, but a good amount are 
fixing recently introduced code.  There's also a lot of "please use 
range base for" comments appearing in code review which could be easily 
automated if something like clang-modernize was run on a regular basis.

A better distinction would be to have sub-categories of 
transforms/warnings in clang-tidy which only apply to particular 
language versions.

Philip