MyDeveloperDay marked an inline comment as done. MyDeveloperDay added a comment.
> I think it's easy enough to do as a kind of driver, either in python or C++, > but then again, at that point putting it into ClangFormat seems fine. One > thing that I find on the one side kinda nice, but on the other side also > weird is the names of the flags. Making them more similar to clang flags is > nice from the point of people used to clang being able to quickly identify > them, but the structure also makes it look like clang-format would support a > wider range of flags, which it doesn't. Not sure which side I'm on, and I'm > fine with the patch as is (minus pulling out a function), but wanted to bring > it up if folks have ideas. The reason I added -Wclang-format-violations and -Wnoclang-format-violations was not only because I wanted to treat them like compiler warnings, but also so that the command line argument could be used the turning on/off to alter the exit code so as to either stop a build or continue based on -Werror or if you'd turn the individual warning off. Also I know there are external tools, (I think SonarCube) which I think could read the code in the [] e.g. 'ClangFormat.cpp:54:29: warning: code should be clang-formatted [-Wclang-format-violations]' and be able to use that along with the file, row and column information to categorize and the annotate source code. if you think this is too much perhaps I should make a new tool `clang-format-check` that did only this, but then I am concerned that it would be almost 100% clang-format anyway, and it wouldn't be long before a request came in to merge the functionality. Let me update the patch so it looks even less invasive. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68554/new/ https://reviews.llvm.org/D68554 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
