[PATCH] D69433: [clang-format] [NFC] update the documentation in Format.h to allow dump_format_style.py to get a little closer to being correct. (part 2)

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.

Apologies for this mess, I didn't know about dump_format_style. Thanks for cleaning this up!

Generally the differences were intentional and I think the text in Format.h was mostly better :-( Happy to unify but a bunch of suggestions accordingly.



================
Comment at: clang/docs/ClangFormatStyleOptions.rst:2336
     Use C++03-compatible syntax.
+    ``Cpp03``: deprecated alias for ``c++03``
 
----------------
`Cpp03` is a deprecated alias for `c++03`.
The colons were just to give terse bullets, these are no longer bullets and I think they hurt readability.


================
Comment at: clang/docs/ClangFormatStyleOptions.rst:2343
     Use C++14-compatible syntax.
+    ``Cpp11``: deprecated alias for ``Latest``
 
----------------
I'm not sure why this is grouped here. Did you intend this to be under `LS_Latest`?


================
Comment at: clang/docs/ClangFormatStyleOptions.rst:2343
     Use C++14-compatible syntax.
+    ``Cpp11``: deprecated alias for ``Latest``
 
----------------
sammccall wrote:
> I'm not sure why this is grouped here. Did you intend this to be under `LS_Latest`?
`Cpp11` is a deprecated alias for `Latest`, for historical reasons.


================
Comment at: clang/docs/tools/dump_format_style.py:175
+        val = line.replace(',', '')
+        pos = val.find(" // ")
+        if (pos != -1):
----------------
MyDeveloperDay wrote:
> MyDeveloperDay wrote:
> > mitchell-stellar wrote:
> > > MyDeveloperDay wrote:
> > > > mitchell-stellar wrote:
> > > > > This seems quite flimsy to me, as it depends on an undocumented comment style. It is true that if the file(s) in question are properly clang-formatted, then this would probably not fail, but it does not appear to be a very robust solution.
> > > > I'd tend to agree, but this whole dump_format_style.py is flimsy.. take a look at this review {D31574} 
> > > > 
> > > > When you added this line, you forgot the third /
> > > > 
> > > > ```// Different ways to wrap braces after control statements.```
> > > > 
> > > > Also, the extra empty line in the LanguageStandard both caused the whole python file to fail with an exception.
> > > > 
> > > > Do you have a suggestion for something better? (which doesn't leave the Format.h looking too odd)
> > > I would go back to the `/// c++03: Parse and format as C++03.` style. `///` is a Doxygen comment, and I think documentation should be generated solely from Doxygen comments, even if it requires a bit of post-processing. (The extra `/` needed after `//` in the ticket you mentioned is justified.)
> > The Doxygen documentation is used for source-level documentation, this is user-level documentation which the restructured text output .rst is used.
> > 
> > In the past the ClangFormatStyleOpions.rst has been generated from the Format.h via this script, we should break that.
> > 
> > The "In configuation" part is super important because it explains to user what to put into their .clang-format file.
> > 
> > We have to either have some form of markup that says `LS_Cpp03 == c++03` in the documentation
> *we shouldn't break that*
> The "In configuation" part is super important because it explains to user what to put into their .clang-format file.

Honestly, I'm not sure why the docs say "LS_Foo (in configuration: Foo)" rather than just "Foo" - why do users care what the enum is?

But this is an existing practice, and should be changed separately if at all.


================
Comment at: clang/include/clang/Format/Format.h:1986
   /// The historical aliases ``Cpp03`` and ``Cpp11`` are deprecated.
   enum LanguageStandard {
+    /// Use C++03-compatible syntax.
----------------
MyDeveloperDay wrote:
> Again focus is on the rst being the desired text and getting them to be aligned. @sammccall  please correct me if my assumption is incorrect
I think "Parse and format as C++03" is better here. In the RST it's redundant, as the description for `Standard` precedes this block. But if we have to pick one, I'd go with "Parse and format as C++03".


================
Comment at: clang/include/clang/Format/Format.h:2001
     LS_Latest,
-    /// Auto: Automatic detection based on the input.
-    /// Parse using the latest language version. Format based on detected input.
+    /// Automatic detection based on the input.
     LS_Auto,
----------------
The new text (two lines) is better, please add it back.


================
Comment at: clang/include/clang/Format/Format.h:2005
 
-  /// Format compatible with this standard, e.g. use ``A<A<int> >``
-  /// instead of ``A<A<int>>`` for ``LS_Cpp03``.
+  /// Parse and Format C++ constructs compatible with this standard.
+  /// \code
----------------
nit: "Parse and Format" -> "Parse and format"


Repository:
  rC Clang

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

https://reviews.llvm.org/D69433