MyDeveloperDay added a comment. In D68554#1697857 <https://reviews.llvm.org/D68554#1697857>, @mitchell-stellar wrote:
> I don't care for the command line switches that try to emulate compiler > flags. I am also of the opinion that external scripts should be used for this > functionality. git for Windows gives you a full set of bash utilities to > utilize, so doing stuff like this on Windows is much easier now. For me, this is about easy integration into IDEs and build systems of a variety of flavours (make,cmake,msbuild,VS,etc..) so clang-format can be run as a pre/post build step. It's not that it can't be done without using a series of scripts and additional processes like find/python/grep etc.. its just its a right pain! I often find I have to jump through hoops to get Visual Studio's build steps to work calling external scripts, (often calling a .bat file, which runs a bash file etc...) pulling some of that functionality into clang-format prevents the need to jump through those hoops. (I see this as no different to grep having a -r option? why do that when you could use find?) The ironic thing is I run this on my local build for clang-format itself and it catches when people ask me to land their patches but they haven't remembered to git clang-format, and that is the point of the proposal, people either can't or don't run arc lint, they forget to run git clang-format and code creeps back in (even into clang-format) that is unformatted. This is why it needs to be part of the build step and it needs to present itself in a way people are expecting from a compiler, especially so the buildbot picks this output up and presents it as a warning, and ultimately so we can stop saying in code review "please clang format". The compiler like switches -Werror, and -ferror-limit=1 allow you to either stop your build or get a single warning per file giving you fine control about how invasive this is for your build output. Having the output emulate the compiler output also has the added advantage of allowing a user to double click on the error/warning in visual studio and be taken to the exact format violation, (this has been especially useful as I inspect the C# in .NET core, whilst I try to work out what rules I'm missing for formatting C#), I could see the same would be useful for someone adopting clang-format and trying to determine which options to use and exactly how much code will change. (again this is something I use on clang-format myself when we make a code change, I quickly run this over a known formatted source tree to see what files are going to change if any, this lets me assess the change beyond what the unit tests are testing) In case others are interested, I've landed this behaviour in my own experimental fork and made a release if people would like to try. https://github.com/mydeveloperday/clang-experimental I take your points, but I think its worth it, given how simple the change is. 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
