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



More information about the cfe-commits mailing list