clang-tidy, clang-modernize, and remove-cstr-calls

Hi,

The description for clang-tidy[1] says:

    "clang-tidy is a clang-based C++ linter tool. Its purpose is to
    provide an extensible framework for diagnosing and fixing typical
    programming errors, like style violations, interface misuse, or
    bugs that can be deduced via static analysis. clang-tidy is
    modular and provides a convenient interface for writing new
    checks."

clang-tidy is a bit odd in that it can be used in either detection
mode (report problems like a standard lint tool) or "fix" mode
(refactor the problem away, which no lint tool ever did).

So the "remove void argument"[2] tool that I've been working on feels
like it fits in with clang-tidy.

My tool is very much patterned on remove-cstr-calls tool, which isn't
documented on the web site.

Should remove-cstr-calls be migrated to a clang-tidy check?

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?

[1] <http://clang.llvm.org/extra/clang-tidy.html>
[2] <https://github.com/legalizeadulthood/remove-void-args>

Richard <legalize@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.

It was the plan from the beginning of the design of clang-tidy to eventually make tools like clang-modernize and checks like the redundant-cstr-check part of it.

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

In article <54D111E9.3090001@philipreames.com>,
    Philip Reames <listmail@philipreames.com> writes:

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

If I was going to fold clang-modernize into clang-tidy, I'd make a
"modernize" module for clang-tidy. What's interesting is that there
are "modernizations" to bring code into realm of C++98 or C++03 that
would apply to lots of C++ code I've seen over the years. There are a
lot of C habits that are really having a hard time dying.