[clang-format] Proposal for clang-format to give compiler style warnings

[MyDeveloperDay]

Summary

Related somewhat to D29039: [clang-format] Proposal for clang-format -r option

On seeing a quote on twitter by @invalidop

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

This made me want to change the way I use clang-format into a tool that could optionally show me where my source code violates clang-format syle.

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 in a manner I'm used to.

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 a 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.

I am starting this by suggesing adding a -n or -dry-run command line argument which would emit a warning/error of the form

Support for various common compiler command line argumuments like '-Werror' and '-ferror-limit' could make this very flexible to be integrated into build systems and CI systems.

> $ /usr/bin/clang-format --dry-run ClangFormat.cpp -ferror-limit=3 -fcolor-diagnostics
> ClangFormat.cpp:54:29: warning: code should be clang-formatted [-Wclang-format-violations]
> static cl::list<std::string>
>                             ^
> ClangFormat.cpp:55:20: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
>                    ^
> ClangFormat.cpp:55:77: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
>                                                                             ^

[klimek]

Why not build a tool that takes the diff output of clang-format and changes it to what you want? Wouldn't that be a couple of lines of python?

[MyDeveloperDay]

In D68554#1696675, @klimek wrote:

Why not build a tool that takes the diff output of clang-format and changes it to what you want? Wouldn't that be a couple of lines of python?

Thanks for taking the time to look at this idea. At least initially I can see that that would seem like a low impact way of doing it, and this also relates to D29039: [clang-format] Proposal for clang-format -r option, initially I felt this is not clang-formats job.. but the more I look online the more I see people using tricks to parse the output-replacements-xml

https://stackoverflow.com/questions/22866609/can-clang-format-tell-me-if-formatting-changes-are-necessary

But really what it means is each developer/group has to come up with their own solution or we have to develop some external python script.

But take a look at the hoops people are jumping thought just to determine if something needs to be formatted. All the additional tools like find/xargs/grep and these tools aren't always truly cross-platform, throw in additional complications of those people not using WSL,MingW or Cygwin and you now need a powershell or cmd.exe solution too. To make matters work every build system is different or needs some $shell() magic to run a series of commands, and all of that's before we even mention the whole python issue of getting it to work reliably in both Cygwin and/or Windows. (did I even mention the whole color diagnostics etc.. that you get for free by reusing the LLVM classes)

When you consider that really apart of the setting up of the DiagnosticsEngine (which is a large portion of this code change), its actually quite a small fix. (which still needs lit tests in clang/test/Format I know, I'm trying to get those working and failing miserably)

This idea really amounts to making the xml <replacements> human-readable, in a way in which both developers but also build systems which are used to parsing and/or displaying the output of compilers know and understand.

Like the quote says, its about making clang-format violations seem much more like build errors:

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

[MyDeveloperDay]

Using a suggestion from D68551: [clang-format] [NFC] Ensure clang-format is itself clang-formatted. as an example of its usefulness, I modified my clang-format CMakeList.txt to do as Polly does and add clang-format check rules, combining this with this revision gives a nice integration into the build system that lets you quickly and easily see where violations creep in.

I really feel this could help bring clang-format checking into developers build workflows using a similar mechanism and it really highlights what is clean and what is not.

# Add target to check formatting of files
file( GLOB files *.cpp ../../lib/Format/*.cpp ../../lib/Format*.h ../../unittests/Format/*.cpp ../../include/clang/Format.h)

set(check_format_depends)
set(update_format_depends)
set(i 0)
foreach (file IN LISTS files)
  add_custom_command(OUTPUT clang-format-check-format${i}
    COMMAND clang-format -i -ferror-limit=1 --dry-run -sort-includes -style=llvm ${file}
    VERBATIM
    COMMENT "Checking format of ${file}..."
  )
  list(APPEND check_format_depends "clang-format-check-format${i}")

  add_custom_command(OUTPUT clang-format-update-format${i}
    COMMAND clang-format -sort-includes -i -style=llvm ${file}
    VERBATIM
    COMMENT "Updating format of ${file}..."
  )
  list(APPEND update_format_depends "clang-format-update-format${i}")

  math(EXPR i ${i}+1)
endforeach ()

add_custom_target(clang-format-check-format DEPENDS ${check_format_depends})
set_target_properties(clang-format-check-format PROPERTIES FOLDER "ClangFormat")

add_custom_target(clang-format-update-format DEPENDS ${update_format_depends})
set_target_properties(clang-format-update-format PROPERTIES FOLDER "ClangFormat")

[ 94%] Built target obj.clangSema
[ 94%] Built target clangAST
[ 94%] Built target clangSema
[ 94%] Built target clang-format
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/AffectedRangeManager.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/BreakableToken.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/ContinuationIndenter.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/FormatToken.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/Format.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/FormatTokenLexer.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/NamespaceEndCommentsFixer.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/SortJavaScriptImports.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/TokenAnalyzer.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/TokenAnnotator.cpp...
[ 94%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/UnwrappedLineFormatter.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/UsingDeclarationsSorter.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/UnwrappedLineParser.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../lib/Format/WhitespaceManager.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/CleanupTest.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTest.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestComments.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestCSharp.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestJS.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestJava.cpp...
C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/CleanupTest.cpp:455:2: warning: code should be clang-formatted [-Wclang-format-violations]
}
 ^
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestProto.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestObjC.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestRawStrings.cpp...
C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestComments.cpp:31:21: warning: code should be clang-formatted [-Wclang-format-violations]
  enum StatusCheck {
                    ^
[100%] C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestJS.cpp:51:47: warning: code should be clang-formatted [-Wclang-format-violations]
    EXPECT_EQ(Code.str(), format(Code, Style))
                                              ^
Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestTableGen.cpp...
[100%] Checking format of C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestSelective.cpp...
C:/llvm/llvm-project/clang/tools/clang-format/../../unittests/Format/FormatTestJava.cpp:455:13: warning: code should be clang-formatted [-Wclang-format-violations]
  EXPECT_EQ(
            ^

[mitchell-stellar]

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.

[MyDeveloperDay]

In 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.

[MyDeveloperDay]

As this behaviour is not something clang-format should do because there are external tool that can do this for us, I thought I'd set myself a challenge of trying to write this with external tools, to prove to myself that it was indeed easy, what I want to achieve is being able to go to a directory and determine if there are any clang-format changes needed in the source files of the levels below with a single command.

The idea would be that this could be something that could fit on the command line, or made into a bash alias/function (more likely), I really don't want to turn to python as if I'm coding this in another language I might as well be coding it in C++ inside clang-format and it opens me up to the whole can't find the correct python headache. (but I also think the clang diagnostic classes give doing it inside C++ the edge)

I want to take into account at least the concepts from D29039: [clang-format] Proposal for clang-format -r option about being able to look deeply into a directory.

There are a couple of requirements: (some nice to have's)

1. look deeply into a directory for all files supported by clang-format (C++,C# etc)
2. file extensions should be case insensitive i.e. .cpp or .CPP
3. be able to clearly see the name of the file that need clang-formatting
4. don't actually do the formatting (tell me what needs doing but don't necessarily make the change)
5. ideally show a snippet of the file where the change is needed (I guess this isn't essential)
6. This should be cross platform windows, linux, (I guess other *nix's) it should work in at least the common shells bash,cygwin,powershell

The cross platform is the real killer, this forces you down the python road, (or the C++) if you want a common solution otherwise you are implementing different solutions on different plaforms.

But lets ignore that and lets start with a Linux or Cygwin bash shell. Surely the best way to find all source files that can be converted is via a find. In the past I've only ever used find like this to find multiple extensions

find .\( -name "*.h" -o name "*.cpp" \) -print

But this is really unworkable for so many output formats that clang-format supports, and even if you could get that to work it would be case sensitive unless you uses -ilname which would make the command line even longer

So lets try using -iregex, this is a much shorter case insensitive command but still, it needs a certain amount of escaping in the regular expression, (lets hope we never do "clang-format all the things") as this could get longer.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -print

if I want to put that into an alias then I need switch the ' and " around

alias find_all_code='find . -iregex ".*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)" -print'

Is the same thing as easy in powershell? Ok not really .. this is as far as I got, and I couldn't work out how to handle multiple extensions let alone case sensitivity.. (it feels very slow too!)

PowerShell.exe -Command "dir -Recurse -ea 0 | ? FullName -like '*.cpp'

So at least my brief initial conclusion is... if we are not using C++, its Python or nothing if you want cross-platform or maybe find if you only care about *nix

But even the find... that only covers 1) and 2) of my requirements...how do I determine even with find which files need formatting..

This command would show me the contents of everything that needs changing.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format {} \;

This would give me the list of changes, but then I lose the name of the file.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format --output-replacements-xml {} \;

So using external tools is easy how? the dumping of the output to stdout or the replacement xml to stdout makes this much harder as I lose the filename that was passed to clang-format, (there is probably an xargs trick here I'm missing)

This proposed solution would make all this possible just with:

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format -i -n {} \;

and more to the point the list of file types supported by clang-format is something clang-format knows... why not combine this with D29039: [clang-format] Proposal for clang-format -r option and just do

clang-format -r -i -n .

This provides in my view the only cross platform, shell independent way of doing this in what is a relatively minimal code change, and I'm struggling to see this as easy to do with an external tools? but if someone wants to show me how, I'd be interested to learn.

[klimek]

In D68554#1702090, @MyDeveloperDay wrote:

As this behaviour is not something clang-format should do because there are external tool that can do this for us, I thought I'd set myself a challenge of trying to write this with external tools, to prove to myself that it was indeed easy, what I want to achieve is being able to go to a directory and determine if there are any clang-format changes needed in the source files of the levels below with a single command.

The idea would be that this could be something that could fit on the command line, or made into a bash alias/function (more likely), I really don't want to turn to python as if I'm coding this in another language I might as well be coding it in C++ inside clang-format and it opens me up to the whole can't find the correct python headache. (but I also think the clang diagnostic classes give doing it inside C++ the edge)

I want to take into account at least the concepts from D29039: [clang-format] Proposal for clang-format -r option about being able to look deeply into a directory.

There are a couple of requirements: (some nice to have's)

1. look deeply into a directory for all files supported by clang-format (C++,C# etc)
2. file extensions should be case insensitive i.e. .cpp or .CPP
3. be able to clearly see the name of the file that need clang-formatting
4. don't actually do the formatting (tell me what needs doing but don't necessarily make the change)
5. ideally show a snippet of the file where the change is needed (I guess this isn't essential)
6. This should be cross platform windows, linux, (I guess other *nix's) it should work in at least the common shells bash,cygwin,powershell

The cross platform is the real killer, this forces you down the python road, (or the C++) if you want a common solution otherwise you are implementing different solutions on different plaforms.

But lets ignore that and lets start with a Linux or Cygwin bash shell. Surely the best way to find all source files that can be converted is via a find. In the past I've only ever used find like this to find multiple extensions

find .\( -name "*.h" -o name "*.cpp" \) -print

But this is really unworkable for so many output formats that clang-format supports, and even if you could get that to work it would be case sensitive unless you uses -ilname which would make the command line even longer

So lets try using -iregex, this is a much shorter case insensitive command but still, it needs a certain amount of escaping in the regular expression, (lets hope we never do "clang-format all the things") as this could get longer.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -print

if I want to put that into an alias then I need switch the ' and " around

alias find_all_code='find . -iregex ".*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)" -print'

Is the same thing as easy in powershell? Ok not really .. this is as far as I got, and I couldn't work out how to handle multiple extensions let alone case sensitivity.. (it feels very slow too!)

PowerShell.exe -Command "dir -Recurse -ea 0 | ? FullName -like '*.cpp'

So at least my brief initial conclusion is... if we are not using C++, its Python or nothing if you want cross-platform or maybe find if you only care about *nix

But even the find... that only covers 1) and 2) of my requirements...how do I determine even with find which files need formatting..

This command would show me the contents of everything that needs changing.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format {} \;

This would give me the list of changes, but then I lose the name of the file.

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format --output-replacements-xml {} \;

So using external tools is easy how? the dumping of the output to stdout or the replacement xml to stdout makes this much harder as I lose the filename that was passed to clang-format, (there is probably an xargs trick here I'm missing)

This proposed solution would make all this possible just with:

find . -iregex '.*\.\(cpp\|cc\|c\+\+\|cxx\|c\|cl\|h\|hh\|hpp\|m\|mm\|inc\|js\|ts\|protor\|protodevel\|java\|cs\)' -exec clang-format -i -n {} \;

and more to the point the list of file types supported by clang-format is something clang-format knows... why not combine this with D29039: [clang-format] Proposal for clang-format -r option and just do

clang-format -r -i -n .

This provides in my view the only cross platform, shell independent way of doing this in what is a relatively minimal code change, and I'm struggling to see this as easy to do with an external tools? but if someone wants to show me how, I'd be interested to learn.

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.

clang/tools/clang-format/ClangFormat.cpp

445

I'd pull this block out into a function.

[MyDeveloperDay]

clang/tools/clang-format/ClangFormat.cpp

445

me too I've already done that, plus I think I'm leaking the TestDiagnosticPrinter so I've corrected that locally. I'll update the patch but I'd like to do some general tidying too which is why I submitted D68767: [clang-format] NFC - Move functionality into functions to help code structure

[MyDeveloperDay]

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.

[klimek]

In D68554#1703358, @MyDeveloperDay wrote:

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.

I ran thruogh the same line of reasoning in my head when writing my last comment :) The argument about readability of error messages by tools is definitely a good one, so I'd say this is fine.

[MyDeveloperDay]

builds ontop of D68767: [clang-format] NFC - Move functionality into functions to help code structure move replacement warnings into a separate function and move outputXML out into its own function to declutter the format() function a little

[MyDeveloperDay]

In D68554#1703596, @klimek wrote:

I ran through the same line of reasoning in my head when writing my last comment :) The argument about the readability of error messages by tools is definitely a good one, so I'd say this is fine.

that's great

[klimek]

lg

clang/tools/clang-format/ClangFormat.cpp

293

I'd name this getInvalidBOM and make the comment
// If BufStr has an invalid BOM, returns the BOM name; otherwise, returns nullptr.

[MyDeveloperDay]

I'm going to commit this as it was approved, but I've added some simple lit tests, which exposed a double free, I fixed that up, and for the lit tests not to fail with an exit code I now return WarningAsError from the emitReplacements function.

[MyDeveloperDay]

Incorporate feedback from @owenpan on D68767: [clang-format] NFC - Move functionality into functions to help code structure which this revision is reliant upon.

[thakis]

This fails on macOS:

: 'RUN: at line 2';   grep -E "*code should be clang-formatted*" /Users/thakis/src/llvm-project/out/gn/obj/clang/test/Format/Output/dry-run.cpp.tmp.stderr
--
Exit Code: 2

Command Output (stderr):
--
grep: repetition-operator operand invalid

grep -E means extended regex, where you want .* to match anything. But this probably should use FileCheck, or maybe even -verify since you're adding a dep on Frontend anyways.

I've reverted this for now to green up the bots.

For the reland, did y'all consider the impact of this on clang-format build time (it now depends on Frontend and hence on Driver and Sema, and Sema is slow to build) and binary size (it's now basically impossible to ever get the diagnostics tables in clang-format gc'd by the linker)?

It might make sense to instead use LLVM's diag stuff (instead of clang's) since all the actual diags will be disjoint.

[MyDeveloperDay]

I've reverted this for now to green up the bots.

For the reland, did y'all consider the impact of this on clang-format build time (it now depends on Frontend and hence on Driver and Sema, and Sema is slow to build) and binary size (it's now basically impossible to ever get the diagnostics tables in clang-format gc'd by the linker)?

It might make sense to instead use LLVM's diag stuff (instead of clang's) since all the actual diags will be disjoint.

Thanks for doing this, I am struggling to find the MacOS bot log that failed, are any available via Buildbot? (I notice the log looks like your own machine)

I did a quick test, with the backed out change and it's ~200KB bigger with this revision on windows. (that's probably an assertion, debug build) as the last one in the LLVM snapshot builds is only 3,518,976 bytes

-rwxr-xr-x 1 None 15369728 Oct 12 17:36 clang-format-diags.exe
-rwxr-xr-x 1 None 15080960 Oct 13 10:44 clang-format.exe

on my machine, the current release size is just 2,708,480 bytes (I'm using VS2017) - (not sure why its smaller)

-rwxr-xr-x 1 None 2708480 Oct 13 11:00 clang-format.exe

make clang-format build speed with reverted change is 4m12.504s (Release build from clean)

-rwxr-xr-x 1 None 2817024 Oct 13 11:22 clang-format.exe (117KB larger)

make clang-format build speed with unreverted change is 4m51.504s (Release build from clean)

Rebuilding when nothing to rebuild goes from from 5 seconds to 6.7

So as you said it will be a little slower to build clang-format, however, I do notice that all the other clang/tools are pretty much are all building with Frontend. so anyone building a larger range of clang tools probably has everything already built.

I think the main build failure was just the lit tests, I think i would prefer to fix those and reland this as-is, then look for a better diags solution if @klimek thinks this is something I should be concerned about. I really wanted to be able to use a standard Diagnostic front end with all the support for console coloring etc...I'll have to take a look at LLVM's diagnostics to see how that is done.

[thakis]

Thanks for doing this, I am struggling to find the MacOS bot log that failed, are any available via Buildbot? (I notice the log looks like your own machine)

The mac bots are on a different system for some reason: http://green.lab.llvm.org/green/ (see also http://lists.llvm.org/pipermail/llvm-dev/2019-October/135771.html , I wasn't aware of that until a few days ago either).

So as you said it will be a little slower to build clang-format, however, I do notice that all the other clang/tools are pretty much are all building with Frontend. so anyone building a larger range of clang tools probably has everything already built.

I believe all the other clang tools conceptually do semantic analysis, so that makes more sense for them :)

I think the main build failure was just the lit tests, I think i would prefer to fix those and reland this as-is, then look for a better diags solution if @klimek thinks this is something I should be concerned about. I really wanted to be able to use a standard Diagnostic front end with all the support for console coloring etc...I'll have to take a look at LLVM's diagnostics to see how that is done.

I hope my view on this isn't entirely dismissed (see git shortlog -nes clang/lib/Format/).

In addition to the actual size cost of this change: about a third of clang-format's size is the diagnostics table, but before this change here it's kept alive by only two references from lib/Basic and it's reasonably easy to remove these, which should make the binary 1 MB smaller. After this change, that's much harder to do.

LLVM's text diag stuff also supports colors and whatnot.

And another idea: maybe it makes sense to expose these clang-format diagnostics you're adding (which I do think are a cool feature!) via clang-format? That already depends on everything and the kitchen sync, so you could easily output diagnostics from there – and it'd allow clang-format itself to be a tool focused on doing one thing well (namely, formatting code).

[MyDeveloperDay]

In D68554#1707537, @thakis wrote:

Thanks for doing this, I am struggling to find the MacOS bot log that failed, are any available via Buildbot? (I notice the log looks like your own machine)

The mac bots are on a different system for some reason: http://green.lab.llvm.org/green/ (see also http://lists.llvm.org/pipermail/llvm-dev/2019-October/135771.html , I wasn't aware of that until a few days ago either).

So as you said it will be a little slower to build clang-format, however, I do notice that all the other clang/tools are pretty much are all building with Frontend. so anyone building a larger range of clang tools probably has everything already built.

I believe all the other clang tools conceptually do semantic analysis, so that makes more sense for them :)

Agreed..

I think the main build failure was just the lit tests, I think i would prefer to fix those and reland this as-is, then look for a better diags solution if @klimek thinks this is something I should be concerned about. I really wanted to be able to use a standard Diagnostic front end with all the support for console coloring etc...I'll have to take a look at LLVM's diagnostics to see how that is done.

I hope my view on this isn't entirely dismissed (see git shortlog -nes clang/lib/Format/).

Actually I hope not too, I thought this Frontend mechanism was a bit overkill too, but I held back from just doing `llvm::errs() << ..." because I felt that was reinventing the wheel (but it would probably be more space-efficient) especially in terms of dependencies

In addition to the actual size cost of this change: about a third of clang-format's size is the diagnostics table, but before this change here it's kept alive by only two references from lib/Basic and it's reasonably easy to remove these, which should make the binary 1 MB smaller. After this change,

that's much harder to do.

Yes I get that, if I can switch to LLVM diags then I guess can avoid that.  I also wondered if there was some way of me doing this without the `TextDiagnosticPrinter` (which is the only thing that caused Frontend to need to come in, the rest of the Diagnositcs stuff (DiagnosticOptions,DiagnosticEngine etc..) was already being used.

LLVM's text diag stuff also supports colors and whatnot.

Could you or anyone else point me to a good example, I'd definitely like to take a look.

And another idea: maybe it makes sense to expose these clang-format diagnostics you're adding (which I do think are a cool feature!) via clang-format? That already depends on everything and the kitchen sync, so you could easily output diagnostics from there – and it'd allow clang-format itself to be a tool focused on doing one thing well (namely, formatting code).

`via clang-format?` did you mean via clang.exe or clang-check.exe?   I did think of this when I started doing this work, I just came to the conclusion that if I did that it wouldn't be long before someone requested the same features in clang-format itself.

I think from what you've said, trying to break the Frontend dependency is probably important, as for a dependency on lib/Basic I feel I was just asked to make that worse {D68914} perhaps that's why the code was duplicated in the first place...

bear with me I'm still learning all this stuff.

[thakis]

Could you or anyone else point me to a good example, I'd definitely like to take a look.

http://llvm-cs.pcc.me.uk/include/llvm/Support/SourceMgr.h/rSMDiagnostic --

`via clang-format?` did you mean via clang.exe or clang-check.exe?   I did think of this when I started doing this work, I just came to the conclusion that if I did that it wouldn't be long before someone requested the same features in clang-format itself.

Err, via clang-tidy. Sorry, that was a super confusing typo. That seems like a great place for this feature to me.

[klimek]

In D68554#1707540, @thakis wrote:

Could you or anyone else point me to a good example, I'd definitely like to take a look.

http://llvm-cs.pcc.me.uk/include/llvm/Support/SourceMgr.h/rSMDiagnostic --

`via clang-format?` did you mean via clang.exe or clang-check.exe?   I did think of this when I started doing this work, I just came to the conclusion that if I did that it wouldn't be long before someone requested the same features in clang-format itself.

Err, via clang-tidy. Sorry, that was a super confusing typo. That seems like a great place for this feature to me.

clang-tidy is a compiler tool that needs the full compile info, while clang-format is just a parser; I think it'd be actively confusing to have clang-tidy be a clang-format frontend given how different there usage is.

That said, I agree it's worth looking into using LLVM Diags without all of Clang's overhead.

[sylvestre.ledru]

@MyDeveloperDay I think it should be added to the release notes. it is a great new changes for clang format (it would have made my life at Mozilla much easier ;)

[MyDeveloperDay]

In D68554#1709316, @sylvestre.ledru wrote:

@MyDeveloperDay I think it should be added to the release notes. it is a great new changes for clang format (it would have made my life at Mozilla much easier ;)

I agree, to be honest, I like the way clang-tidy does their release notes, that new items are announced, I think it would be useful here to just say a few sentences about new features.

[MyDeveloperDay]

In D68554#1709316, @sylvestre.ledru wrote:

@MyDeveloperDay I think it should be added to the release notes. it is a great new changes for clang format (it would have made my life at Mozilla much easier ;)

I am super honoured you think this is a good change, to be honest in using it this week, I've spent so much time typing find . -name '*.cpp' ... I am even more convinced we need a recursive -r option something like D29039: [clang-format] Proposal for clang-format -r option so plan to pursue that more.

I can't wait for @hans next Windows Snapshot, this is my gate for rolling into our builds and CI system, after that, I'm gonna catch every single person who tries to build/check in unclang-formatted.

[hans]

I can't wait for @hans next Windows Snapshot, this is my gate for rolling into our builds and CI system, after that, I'm gonna catch every single person who tries to build/check in unclang-formatted.

As it happens, there's a new snapshot out today :-)

[MyDeveloperDay]

In D68554#1712863, @hans wrote:

I can't wait for @hans next Windows Snapshot, this is my gate for rolling into our builds and CI system, after that, I'm gonna catch every single person who tries to build/check in unclang-formatted.

As it happens, there's a new snapshot out today :-)

@MyDeveloperDay awarded this comment a like token!!! (if I could)

[hliao]

clang/test/Format/dry-run-alias.cpp

2–3

Why not check with FileCheck?

clang/test/Format/dry-run.cpp

2–3

Why not check with FileCheck?

[MyDeveloperDay]

clang/test/Format/dry-run-alias.cpp

2–3

Absolutely no real reason other than my lack of ability to get it working correctly. I was trying to follow the other examples of how it could be written with FIleCheck but failed. In the end, I copied how it was done in some of the other tests for now but If someone could help me I would love to change them to use FileCheck properly.

[sylvestre.ledru]

I reported a small issue here: https://bugs.llvm.org/show_bug.cgi?id=45441

clang/test/Format/dry-run-alias.cpp

+// RUN: clang-format -style=LLVM -i -n %s 2> %t.stderr
+// RUN: grep -E "*code should be clang-formatted*" %t.stderr
+
+int a ;

clang/test/Format/dry-run.cpp

+// RUN: clang-format -style=LLVM -i --dry-run %s 2> %t.stderr
+// RUN: grep -E "*code should be clang-formatted*" %t.stderr
+
+int a ;

clang/tools/clang-format/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS support)
 
 add_clang_tool(clang-format
   ClangFormat.cpp
   )
 
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat
+  clangFrontend
   clangRewrite
   clangToolingCore
   )
 
 clang_target_link_libraries(clang-format
   PRIVATE
   ${CLANG_FORMAT_LIB_DEPS}
   )

clang/tools/clang-format/ClangFormat.cpp

 //===----------------------------------------------------------------------===//
 
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/Process.h"
 
 using namespace llvm;
 using clang::tooling::Replacements;
static cl::opt<bool> SortIncludes(
     cl::desc("If set, overrides the include sorting behavior determined by the "
              "SortIncludes style flag"),
     cl::cat(ClangFormatCategory));
 
 static cl::opt<bool>
     Verbose("verbose", cl::desc("If set, shows the list of processed files"),
             cl::cat(ClangFormatCategory));
 
+// Use --dry-run to match other LLVM tools when you mean do it but don't
+// actually do it
+static cl::opt<bool>
+    DryRun("dry-run",
+           cl::desc("If set, do not actually make the formatting changes"),
+           cl::cat(ClangFormatCategory));
+
+// Use -n as a common command as an alias for --dry-run. (git and make use -n)
+static cl::alias DryRunShort("n", cl::desc("Alias for --dry-run"),
+                             cl::cat(ClangFormatCategory), cl::aliasopt(DryRun),
+                             cl::NotHidden);
+
+// Emulate being able to turn on/off the warning.
+static cl::opt<bool>
+    WarnFormat("Wclang-format-violations",
+               cl::desc("Warnings about individual formatting changes needed. "
+                        "Used only with --dry-run or -n"),
+               cl::init(true), cl::cat(ClangFormatCategory), cl::Hidden);
+
+static cl::opt<bool>
+    NoWarnFormat("Wno-clang-format-violations",
+                 cl::desc("Do not warn about individual formatting changes "
+                          "needed. Used only with --dry-run or -n"),
+                 cl::init(false), cl::cat(ClangFormatCategory), cl::Hidden);
+
+static cl::opt<unsigned> ErrorLimit(
+    "ferror-limit",
+    cl::desc("Set the maximum number of clang-format errors to emit before "
+             "stopping (0 = no limit). Used only with --dry-run or -n"),
+    cl::init(0), cl::cat(ClangFormatCategory));
+
+static cl::opt<bool>
+    WarningsAsErrors("Werror",
+                     cl::desc("If set, changes formatting warnings to errors"),
+                     cl::cat(ClangFormatCategory));
+
+static cl::opt<bool>
+    ShowColors("fcolor-diagnostics",
+               cl::desc("If set, and on a color-capable terminal controls "
+                        "whether or not to print diagnostics in color"),
+               cl::init(true), cl::cat(ClangFormatCategory), cl::Hidden);
+
+static cl::opt<bool>
+    NoShowColors("fno-color-diagnostics",
+                 cl::desc("If set, and on a color-capable terminal controls "
+                          "whether or not to print diagnostics in color"),
+                 cl::init(false), cl::cat(ClangFormatCategory), cl::Hidden);
+
 static cl::list<std::string> FileNames(cl::Positional, cl::desc("[<file> ...]"),
                                        cl::cat(ClangFormatCategory));
 
 namespace clang {
 namespace format {
 
 static FileID createInMemoryFile(StringRef FileName, MemoryBuffer *Source,
                                  SourceManager &Sources, FileManager &Files,
for (const auto &R : Replaces) {
     outs() << "<replacement "
            << "offset='" << R.getOffset() << "' "
            << "length='" << R.getLength() << "'>";
     outputReplacementXML(R.getReplacementText());
     outs() << "</replacement>\n";
   }
 }
 
+// If BufStr has an invalid BOM, returns the BOM name; otherwise, returns
+// nullptr.
+static const char *getInValidBOM(StringRef BufStr) {
+  // Check to see if the buffer has a UTF Byte Order Mark (BOM).
+  // We only support UTF-8 with and without a BOM right now.  See
+  // https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding
+  // for more information.
+  const char *InvalidBOM =
+      llvm::StringSwitch<const char *>(BufStr)
+          .StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
+                      "UTF-32 (BE)")
+          .StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
+                      "UTF-32 (LE)")
+          .StartsWith("\xFE\xFF", "UTF-16 (BE)")
+          .StartsWith("\xFF\xFE", "UTF-16 (LE)")
+          .StartsWith("\x2B\x2F\x76", "UTF-7")
+          .StartsWith("\xF7\x64\x4C", "UTF-1")
+          .StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
+          .StartsWith("\x0E\xFE\xFF", "SCSU")
+          .StartsWith("\xFB\xEE\x28", "BOCU-1")
+          .StartsWith("\x84\x31\x95\x33", "GB-18030")
+          .Default(nullptr);
+  return InvalidBOM;
+}
+
+static bool
+emitReplacementWarnings(const Replacements &Replaces, StringRef AssumedFileName,
+                        const std::unique_ptr<llvm::MemoryBuffer> &Code) {
+  if (Replaces.empty()) {
+    return false;
+  }
+
+  IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
+  DiagOpts->ShowColors = (ShowColors && !NoShowColors);
+
+  TextDiagnosticPrinter *DiagsBuffer =
+      new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts, false);
+
+  IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
+  IntrusiveRefCntPtr<DiagnosticsEngine> Diags(
+      new DiagnosticsEngine(DiagID, &*DiagOpts, DiagsBuffer));
+
+  IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> InMemoryFileSystem(
+      new llvm::vfs::InMemoryFileSystem);
+  FileManager Files(FileSystemOptions(), InMemoryFileSystem);
+  SourceManager Sources(*Diags, Files);
+  FileID FileID = createInMemoryFile(AssumedFileName, Code.get(), Sources,
+                                     Files, InMemoryFileSystem.get());
+
+  const unsigned ID = Diags->getCustomDiagID(
+      WarningsAsErrors ? clang::DiagnosticsEngine::Error
+                       : clang::DiagnosticsEngine::Warning,
+      "code should be clang-formatted [-Wclang-format-violations]");
+
+  unsigned Errors = 0;
+  DiagsBuffer->BeginSourceFile(LangOptions(), nullptr);
+  if (WarnFormat && !NoWarnFormat) {
+    for (const auto &R : Replaces) {
+      Diags->Report(
+          Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()),
+          ID);
+      Errors++;
+      if (ErrorLimit && Errors >= ErrorLimit)
+        break;
+    }
+  }
+  DiagsBuffer->EndSourceFile();
+  return WarningsAsErrors;
+}
+
+static void outputXML(const Replacements &Replaces,
+                      const Replacements &FormatChanges,
+                      const FormattingAttemptStatus &Status,
+                      const cl::opt<unsigned> &Cursor,
+                      unsigned CursorPosition) {
+  outs() << "<?xml version='1.0'?>\n<replacements "
+            "xml:space='preserve' incomplete_format='"
+         << (Status.FormatComplete ? "false" : "true") << "'";
+  if (!Status.FormatComplete)
+    outs() << " line='" << Status.Line << "'";
+  outs() << ">\n";
+  if (Cursor.getNumOccurrences() != 0)
+    outs() << "<cursor>" << FormatChanges.getShiftedCodePosition(CursorPosition)
+           << "</cursor>\n";
+
+  outputReplacementsXML(Replaces);
+  outs() << "</replacements>\n";
+}
+
 // Returns true on error.
 static bool format(StringRef FileName) {
   if (!OutputXML && Inplace && FileName == "-") {
     errs() << "error: cannot use -i when reading from stdin.\n";
     return false;
   }
   // On Windows, overwriting a file with an open file mapping doesn't work,
   // so read the whole file into memory when formatting in-place.
   ErrorOr<std::unique_ptr<MemoryBuffer>> CodeOrErr =
       !OutputXML && Inplace ? MemoryBuffer::getFileAsStream(FileName)
                             : MemoryBuffer::getFileOrSTDIN(FileName);
   if (std::error_code EC = CodeOrErr.getError()) {
     errs() << EC.message() << "\n";
     return true;
   }
   std::unique_ptr<llvm::MemoryBuffer> Code = std::move(CodeOrErr.get());
   if (Code->getBufferSize() == 0)
     return false; // Empty files are formatted correctly.
 
-  // Check to see if the buffer has a UTF Byte Order Mark (BOM).
-  // We only support UTF-8 with and without a BOM right now.  See
-  // https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding
-  // for more information.
   StringRef BufStr = Code->getBuffer();
-  const char *InvalidBOM =
-      llvm::StringSwitch<const char *>(BufStr)
-          .StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
-                      "UTF-32 (BE)")
-          .StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
-                      "UTF-32 (LE)")
-          .StartsWith("\xFE\xFF", "UTF-16 (BE)")
-          .StartsWith("\xFF\xFE", "UTF-16 (LE)")
-          .StartsWith("\x2B\x2F\x76", "UTF-7")
-          .StartsWith("\xF7\x64\x4C", "UTF-1")
-          .StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
-          .StartsWith("\x0E\xFE\xFF", "SCSU")
-          .StartsWith("\xFB\xEE\x28", "BOCU-1")
-          .StartsWith("\x84\x31\x95\x33", "GB-18030")
-          .Default(nullptr);
+
+  const char *InvalidBOM = getInValidBOM(BufStr);
 
   if (InvalidBOM) {
     errs() << "error: encoding with unsupported byte order mark \""
            << InvalidBOM << "\" detected";
     if (FileName != "-")
       errs() << " in file '" << FileName << "'";
     errs() << ".\n";
     return true;
if (!ChangedCode) {
     return true;
   }
   // Get new affected ranges after sorting `#includes`.
   Ranges = tooling::calculateRangesAfterReplacements(Replaces, Ranges);
   FormattingAttemptStatus Status;
   Replacements FormatChanges =
       reformat(*FormatStyle, *ChangedCode, Ranges, AssumedFileName, &Status);
   Replaces = Replaces.merge(FormatChanges);
-  if (OutputXML) {
-    outs() << "<?xml version='1.0'?>\n<replacements "
-              "xml:space='preserve' incomplete_format='"
-           << (Status.FormatComplete ? "false" : "true") << "'";
-    if (!Status.FormatComplete)
-      outs() << " line='" << Status.Line << "'";
-    outs() << ">\n";
-    if (Cursor.getNumOccurrences() != 0)
-      outs() << "<cursor>"
-             << FormatChanges.getShiftedCodePosition(CursorPosition)
-             << "</cursor>\n";
-
-    outputReplacementsXML(Replaces);
-    outs() << "</replacements>\n";
+  if (OutputXML || DryRun) {
+    if (DryRun) {
+      return emitReplacementWarnings(Replaces, AssumedFileName, Code);
+    } else {
+      outputXML(Replaces, FormatChanges, Status, Cursor, CursorPosition);
+    }
   } else {
     IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> InMemoryFileSystem(
         new llvm::vfs::InMemoryFileSystem);
     FileManager Files(FileSystemOptions(), InMemoryFileSystem);
     DiagnosticsEngine Diagnostics(
         IntrusiveRefCntPtr<DiagnosticIDs>(new DiagnosticIDs),
         new DiagnosticOptions);
     SourceManager Sources(Diagnostics, Files);

 
 } // namespace format
 } // namespace clang
 
 static void PrintVersion(raw_ostream &OS) {
   OS << clang::getClangToolFullVersion("clang-format") << '\n';
 }
 
-int main(int argc, const char **argv) {
-  llvm::InitLLVM X(argc, argv);
-
-  cl::HideUnrelatedOptions(ClangFormatCategory);
-
-  cl::SetVersionPrinter(PrintVersion);
-  cl::ParseCommandLineOptions(
-      argc, argv,
-      "A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.\n\n"
-      "If no arguments are specified, it formats the code from standard input\n"
-      "and writes the result to the standard output.\n"
-      "If <file>s are given, it reformats the files. If -i is specified\n"
-      "together with <file>s, the files are edited in-place. Otherwise, the\n"
-      "result is written to the standard output.\n");
-
-  if (Help) {
-    cl::PrintHelpMessage();
-    return 0;
-  }
-
-  if (DumpConfig) {
-    StringRef FileName;
-    std::unique_ptr<llvm::MemoryBuffer> Code;
-    if (FileNames.empty()) {
-      // We can't read the code to detect the language if there's no
-      // file name, so leave Code empty here.
-      FileName = AssumeFileName;
-    } else {
-      // Read in the code in case the filename alone isn't enough to
-      // detect the language.
-      ErrorOr<std::unique_ptr<MemoryBuffer>> CodeOrErr =
-          MemoryBuffer::getFileOrSTDIN(FileNames[0]);
-      if (std::error_code EC = CodeOrErr.getError()) {
-        llvm::errs() << EC.message() << "\n";
-        return 1;
-      }
-      FileName = (FileNames[0] == "-") ? AssumeFileName : FileNames[0];
-      Code = std::move(CodeOrErr.get());
-    }
-    llvm::Expected<clang::format::FormatStyle> FormatStyle =
-        clang::format::getStyle(Style, FileName, FallbackStyle,
-                                Code ? Code->getBuffer() : "");
-    if (!FormatStyle) {
-      llvm::errs() << llvm::toString(FormatStyle.takeError()) << "\n";
-      return 1;
-    }
-    std::string Config = clang::format::configurationAsText(*FormatStyle);
-    outs() << Config << "\n";
-    return 0;
-  }
+// Dump the configuration.
+static unsigned dumpConfig(StringRef AssumeFileName) {
 
+int main(int argc, const char **argv) {
+  llvm::InitLLVM X(argc, argv);
+
+  cl::HideUnrelatedOptions(ClangFormatCategory);
+
+  cl::SetVersionPrinter(PrintVersion);
+  cl::ParseCommandLineOptions(
+      argc, argv,
+      "A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.\n\n"
+      "If no arguments are specified, it formats the code from standard input\n"
+      "and writes the result to the standard output.\n"
+      "If <file>s are given, it reformats the files. If -i is specified\n"
+      "together with <file>s, the files are edited in-place. Otherwise, the\n"
+      "result is written to the standard output.\n");
+
+  if (Help) {
+    cl::PrintHelpMessage();
+    return 0;
+  }
+
+  if (DumpConfig) {
+    return dumpConfig(AssumeFileName);
+  }
+
   bool Error = false;
   if (FileNames.empty()) {
     Error = clang::format::format("-");
     return Error ? 1 : 0;
   }
   if (FileNames.size() != 1 &&
       (!Offsets.empty() || !Lengths.empty() || !LineRanges.empty())) {
     errs() << "error: -offset, -length and -lines can only be used for "