Added note about Whatstyle and Unformat

[owenpan]

Summary

I added a note about Whatstyle and Unformat in the docs.

[MyDeveloperDay]

Whatstyle has not been updated since Dec 2020, is it going to cover the latest style configuration options?

[Volker-Weissmann]

In D110252#3018375, @MyDeveloperDay wrote:

Whatstyle has not been updated since Dec 2020, is it going to cover the latest style configuration options?

No it doesn't.
As I wrote, both work on a best-effort basis. I tried them myself, they are far from guaranteed to give you the correct .clang-format file. But it's better than nothing.

[MyDeveloperDay]

IMHO is that I don't personally feel we need to endorse the work of someone else that could be potentially incomplete, These tools are interesting (per say) but I have no idea how accurate they are in terms of using all the options or how much they keep pace, for everything else there is "google search" to find these, (other search engines are available)

My feeling is that if you are using this tool then perhaps you are rushing to get to your format and you should be either :

a) picking a default style
b) taking a bit more time to read the manual and choose what you want.

Those tools suggest a quick fix, but come with extra effort to get them installed (extra python modules) and I personally wouldn't want clang-format to be somehow responsible if they generate an incorrect .clang-format file or messed up someones files.

I'll let others decide if they think it's of value but for me it's a no (sorry just my 2c worth).

[HazardyKnusperkeks]

I too think this should not directly mentioned in clang-format documentation.

[Volker-Weissmann]

I understand your concerns, it isn't meant as an endorsement. I took me quite a while too find them with google, so I thought I make it faster for the next one after me.

NOTE: Clang-Format Team Automated Review Comment

Your review contains a change to ClangFormatStyleOptions.rst but not a change to clang/include/clang/Format/Format.h

ClangFormatStyleOptions.rst is auto generated from Format.h via clang/docs/tools/dump_format_style.py, please run this to regenerate the .rst

You can validate that the rst is valid by running.

./docs/tools/dump_format_style.py
mkdir -p html
/usr/bin/sphinx-build -n ./docs ./html

NOTE: Clang-Format Team Automated Review Comment

It looks like your clang-format review does not contain any unit tests, please try to ensure all code changes have a unit test (unless this is an NFC or refactoring, adding documentation etc..)

Add your unit tests in clang/unittests/Format and you can build with ninja FormatTests. We recommend using the verifyFormat(xxx) format of unit tests rather than EXPECT_EQ as this will ensure you change is tolerant to random whitespace changes (see FormatTest.cpp as an example)

For situations where your change is altering the TokenAnnotator.cpp which can happen if you are trying to improve the annotation phase to ensure we are correctly identifying the type of a token, please add a token annotator test in TokenAnnotatorTest.cpp

clang/docs/ClangFormatStyleOptions.rst

 
 When specifying configuration in the ``-style=`` option, the same configuration
 is applied for all input files. The format of the configuration is:
 
 .. code-block:: console
 
   -style='{key1: value1, key2: value2, ...}'
 
+`Whatstyle <https://github.com/mikr/whatstyle>`_ and `Unformat
+<https://github.com/johnmcfarlane/unformat>`_ can generate a .clang-format file
+from an existing codebase. Note that both of those tools are not officially
+supported and work on a best-effort basis.
+
 
 Disabling Formatting on a Piece of Code
 =======================================
 
 Clang-format understands also special comments that switch formatting in a
 delimited range. The code between a comment ``// clang-format off`` or
 ``/* clang-format off */`` up to a comment ``// clang-format on`` or
 ``/* clang-format on */`` will not be formatted. The comments themselves