aaron.ballman added a comment. In D90180#2357178 <https://reviews.llvm.org/D90180#2357178>, @trixirt wrote:
> Discussion of change on LKML > https://lkml.org/lkml/2020/10/27/2538 > > On why the existing clang fixit is not practical. > tl;dr > 10,000 changes to look for a treewide fix > The fixit has whitespace issue When you pass `-fix` to clang-tidy, it will apply fix-its from the compiler as well. See https://godbolt.org/z/7vzM4b and try adding a semicolon to the end of the `switch` statement and note how it's removed when recompilation happens. What's more, the frontend will generate fix-its on some compile errors as well, so passing `-fix` may generate more changes than just removing semicolons even if you disable all frontend warnings. So if I understand your use case properly, you'd want to disable all frontend warnings, run clang-tidy with just this check enabled and pass `-fix` to be able to automatically catch and fix *only* the case where there's a semicolon after a switch (and just sort of hope that fixits from compile errors are reasonable to look at). Is that any more practical of a scenario? While we have a module for the Linux kernel and it's reasonable to argue that this check certainly applies there, I also think it's defensible to argue that this is a somewhat odd case that's better handled by an out-of-tree script rather than having the community carry around functionality that duplicates what the frontend already supports. Btw, I'd say that the whitespace is not really something we'd consider an issue -- we generally expect the user to format their code changes after applying fix-its. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90180/new/ https://reviews.llvm.org/D90180 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
