[PATCH] D23279: clang-reorder-fields

[Manuel Klimek via cfe-commits]

klimek added a comment.

In https://reviews.llvm.org/D23279#509606, @omtcyfz wrote:

> 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.


Additionally (or alternatively) it might make sense to have a clang-tidy check that re-orders fields to minimize object size.


Repository:
  rL LLVM

https://reviews.llvm.org/D23279