[PATCH] D23279: clang-reorder-fields

[Kirill Bobyrev via cfe-commits]

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D23279