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