[PATCH] D29039: Proposal for clang-format -r option

[MyDeveloperDay via Phabricator via llvm-commits]

MyDeveloperDay added a comment.

When I first saw this issue some time ago I tended to agree with the comment regarding the "its not clang-formats" job to do that...

However, over the last couple of months I've seen more and more twitter and stack-overflow comments regarding "how do I check my whole tree to see what needs clang formatting"

The solutions seem to be a mixture of using various shell tools like find and grep depending if your using cmd,bash,make etc.. and to determine if a change is indeed needed a quite convoluted series of commands looking for greping for "<replacements>"

Finally a quote on twitter by @invalidop may be want to change the way I use clang-format.

> If it's not formatted with clang-format it's a build error.

When I'm making a change to clang-format itself, one thing I like to do to test the change is to ensure I didn't cause a huge wave of changes, what I want to do is simply run this on a known formatted directory and see if any new differences arrive.

This started me thinking that we should allow build systems to run clang-format on a whole tree and emit compiler style warnings about files that fail clang-format in a form that would make them as warning in most build systems and because those build systems range in their construction I don't think its unreasonable to NOT expect them to have to do the directory searching or parsing the output replacements themselves, but simply transform that into an error code when there are changes required.

To this end I would like to resurect these ideas of searching a tree, along with another idea I have regarding adding a -n or -dry-run command line argument which would emit a warning/error of the form

  fileXXX.XXX:29:3: warning: file requires a clang-format [-Wfile-needs-clang-format]

I envisage being able to use -Wno-file-needs-clang-format and  -Werror to escalate them to errors. I know for my own team we'd use this to scan a directory during a build, bring clang-format failures to the front, and this would prevent clang-formatting errors creeping in to the build which seems to happen from the few people who don't use it integrated into an editor or those who forget to run git-clang-format.

my question to you @stryku is are you still interested in pursuing this patch, or are you ok with us consuming it (at least partially) into another piece of work?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D29039/new/

https://reviews.llvm.org/D29039