[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 mailing list