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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
