[PATCH] D23279: clang-reorder-fields
Ben Craig via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 9 11:24:08 PDT 2016
bcraig added a comment.
In https://reviews.llvm.org/D23279#510178, @omtcyfz wrote:
> In https://reviews.llvm.org/D23279#510167, @alexshap wrote:
>
> > my point is the following: this tool helps perform some operation (changing the order of fields),
> > if smb decides to do it manually - the result will have exactly the same issue.
>
>
> While creating tools for automated refactoring our goal is essentially to perform a refactoring action **without** breaking codebases.
For clang-tidy changes, I think that is reasonable. For refactoring, I don't think it is reasonably to have that same expectation. Refactoring an un-inlined method from a .cpp file to an inlined method in a .h can break code. Changing a method signature can definitely break code. Even adding a method (during an "extract") can break code that uses C++ template SFINAE to detect the existence of members. Those are all useful refactorings though, despite the possibility of breakage.
I would like there to be some heuristic for how much breakage is too much breakage though. I don't have a good recommendation for what that heuristic should be. I do think that an automated tool will do a better job of changing field orderings in a non-breaking way than most people would, mostly due to initializer lists.
Repository:
rL LLVM
https://reviews.llvm.org/D23279
More information about the cfe-commits
mailing list