0x8000-0000 added a comment. In D69764#2532952 <https://reviews.llvm.org/D69764#2532952>, @sammccall wrote:
> In D69764#2532666 <https://reviews.llvm.org/D69764#2532666>, @MyDeveloperDay > wrote: > >>> What can be done to move this change along? >> >> I feel there has to be a fundamental acceptance that it is ok for >> clang-format to alter code (something it already does with sorting of >> includes, namespace comments). >> >> There were fairly strong opinions that clang-format isn't the best tool to >> do this (which actually I don't agree with, I think it is, as long as those >> capabilities are off by default and there is an acceptance they won't be >> perfect especially in the presence of macros due to lack of AST) >> >> My only thought about building another tool would be if it was a drop in >> replacement for clang-format (tooling allows setting of a path), but it >> would need to inherit all of clang-format. >> but to me, this just feels like extra grunt work just to work around why >> some community don't like it. > > Yeah, this seems like adding a flag with extra steps. > > clang-format's brand is: > > - fast > - semantic no-op > - applies a consistent, project-specific style > > I think putting it (permanently) behind a flag or alternate binary would cut > against #3. I don't like that. It can naturally be behind a flag, with is: east, west, leave_it_be. Skittish people/teams can leave_it_be for a release or two. > If it's buggy, this feature risks cutting against #2 (more than usual). So > code supporting this feature is more critical than it was previously, and > that might be a lot of heuristics. How is the risk of this bugginess greater than the risk of any other transformation? (header sorting can expose invalid dependencies - and break the build). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69764/new/ https://reviews.llvm.org/D69764 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits