[PATCH] D23279: clang-reorder-fields
Kirill Bobyrev via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 9 02:37:30 PDT 2016
omtcyfz added a comment.
In https://reviews.llvm.org/D23279#509567, @omtcyfz wrote:
> In https://reviews.llvm.org/D23279#509047, @Eugene.Zelenko wrote:
> > May be this could be Clang-rename mode?
> Definitely not.
> I think this is in scope of `clang-tidy`.
> In https://reviews.llvm.org/D23279#509076, @compnerd wrote:
> > This isn't really a renaming tool per se. If you squint really hard, yes, it does rename fields. But, if we really want to save space, perhaps we should collapse all the tools into `clang-tidy` or create a new `clang-refactor` tool and just make the other things a part of that tool in various modes (rename, reorder-fields, extract, etc) via sub-commands (a la git). However, I think thats a broader design decision which could be made outside the context of this change. However, if the concern is purely for install-time, we could add components to the CMake install to control which of the extra tools are built (note that this change doesn't even install the new binary!).
> God, no. Please don't try to add over9000 tools. IMO this perfectly fits into `clang-tidy` scope. And it's not really `refactoring`.
Apologies, I didn't mean to be offensive.
My point, though, is, that we don't want to many tools in `clang-tools-extra` for many reasons. This exact tool doesn't fit into `clang-rename` scope, but at the same time it's not totally in scope of `clang-tidy` either.
It probably **makes** sense to have **clang-refactor** (or something) master tool, to which both tools would belong, but it's not as easy as a patch:
- it needs a good understanding of what would be there
- it needs a proper design
Both things are complex and require a Community-wise discussion.
More information about the cfe-commits