clang-format: Support 'template<>' (no space).

[strager]

Summary

Some styles don't put a space between 'template' and the
opening '<'. Introduce SpaceAfterTemplateKeyword which, when
set to false, causes 'template' and '<' to not have a space
between.

[djasper]

This has come up before and the decision was that this is not important enough to meet the bar for an additional clang-format option. clang-format options have a certain cost and this specific space is so entirely unimportant that we don't want to pay it.

We have tried to eradicate this style wherever we find it (e.g. in the C++ standard) and encourage people to just change their style here if they want to use clang-format.

[MyDeveloperDay]

This looks like a good small change.

What is interesting to me is that even the twiki page about template is inconsistent in its style (https://en.wikipedia.org/wiki/Template_(C%2B%2B)), so its not like there is "one style to rule them all" (some have spaces, some do not)

@djasper, I don't understand here what we mean by "cost" in your review comment (performance, maintainability?), the change has unit tests to keep it honest and its just an additional expression on an 'if', is there something else we should be concerned about when submitting patches? (long term maintainability?)

It does sound a little to me like we might be want to reject it because we don't like this style and don't want to proliferate its continued use, and can't understand why anyone would do it that way. Unfortunately that is not very realistic for those of us who want to introduce clang-format into a code base that predates clang, google and for some of us even the internet! which might have it own style guide which doesn't quite match clang (not quite)

In my view this finite control over every aspect of a style is what clang-format needs, we need clang-format to allow the individuals who maintain large code bases to be able to fine tune the style to meet our companies own documented style, then we can introduce it to automate that style. But the concept that we might be able to alter that style guide of our company and inflict a tidal wave of changes onto previously conforming code is unfortunately not possible.

I know this may not match llvm,clangs requirements but they are possibly the requirements to ensure clang-format becomes completely ubiquitous in the industry.

This review like my own review for similar finite control over else and catch (http://reviews.llvm.org/D12492) is obviously not the way that clang-format wants to go, we want to contribute but can't do it if our patches aren't included, do you have a recommendation?

Could I ask you to reconsider this review, I'm willing to help.

[MyDeveloperDay]

Oh and we might want to run clang-format by the guys at http://cppreference.com seems they don't like the space either! just saying....

[djasper]

The most important costs are: Maintenance and discoverability of options.

The point here that it this space is utterly irrelevant, it doesn't make a
readability difference ever. Most codebases are inconsistent about it
anyway and I haven't seen a style guide even talking about this.

We never intended clang-format to provide control over every aspect of
formatting. We'd rather have it support a limited set of (important) style
options really well.

This simply isn't worth it, not even the time arguing about it.

[MyDeveloperDay]

The point here that it this space is utterly irrelevant

So I totally take the point but if it doesn't matter then why does clang-format automatically add one to my "template<>" why not simply leave it alone?

We never intended clang-format to provide control over every aspect of formatting

I know that when new people come along on an open source project they want to change the world, for that I apologize, we weren't here for the previous decisions, but maybe clang-format is turning into something that is different from what was originally intended, maybe it CAN become the code formatting tool for those teams out there that are not quite/can't do it the google way.

We'd rather have it support a limited set of (important) style options really well

And that I understand, but for those of us whose style does not exactly meet one of the 5 what can WE do other than submit patches to give finer control.

I don't want to argue but I would like you (who seems to be the gatekeeper for clang-format) to consider.

[strager]

Should we remove ObjCSpaceBeforeProtocolList? It has the same problem as the SpaceAfterTemplateKeyword I am introducing.

[djasper]

Lets says this: I am not happy about it and wouldn't allow it if it was
added now. However, *removing* it actually has additional costs, so I am
not inclined to do so now.

[sylvestre.ledru]

This was merged here: https://reviews.llvm.org/D23317
we can close this review

docs/ClangFormatStyleOptions.rst

* ``PAS_Right`` (in configuration: ``Right``)
     Align pointer to the right.
   * ``PAS_Middle`` (in configuration: ``Middle``)
     Align pointer in the middle.
 
 
 **SpaceAfterCStyleCast** (``bool``)
   If ``true``, a space may be inserted after C style casts.
 
+**SpaceAfterTemplateKeyword** (``bool``)
+  If ``true``, a space may be inserted between the 'template' keyword
+  and the following '<'.
+
 **SpaceBeforeAssignmentOperators** (``bool``)
   If ``false``, spaces will be removed before assignment operators.
 
 **SpaceBeforeParens** (``SpaceBeforeParensOptions``)
   Defines in which cases to put a space before opening parentheses.
 
   Possible values:
 

include/clang/Format/Format.h

struct FormatStyle {
   };
 
   /// Pointer and reference alignment style.
   PointerAlignmentStyle PointerAlignment;
 
   /// \brief If \c true, a space may be inserted after C style casts.
   bool SpaceAfterCStyleCast;
 
+  /// \brief If \c true, a space may be inserted between the 'template' keyword
+  /// and the following '<'.
+  bool SpaceAfterTemplateKeyword;
+
   /// \brief If \c false, spaces will be removed before assignment operators.
   bool SpaceBeforeAssignmentOperators;
 
   /// \brief Different ways to put a space before opening parentheses.
   enum SpaceBeforeParensOptions {
     /// Never put a space before opening parentheses.
     SBPO_Never,
     /// Put a space before opening parentheses only after control statement
return AccessModifierOffset == R.AccessModifierOffset &&
                R.PenaltyBreakBeforeFirstCallParameter &&
            PenaltyBreakComment == R.PenaltyBreakComment &&
            PenaltyBreakFirstLessLess == R.PenaltyBreakFirstLessLess &&
            PenaltyBreakString == R.PenaltyBreakString &&
            PenaltyExcessCharacter == R.PenaltyExcessCharacter &&
            PenaltyReturnTypeOnItsOwnLine == R.PenaltyReturnTypeOnItsOwnLine &&
            PointerAlignment == R.PointerAlignment &&
            SpaceAfterCStyleCast == R.SpaceAfterCStyleCast &&
+           SpaceAfterTemplateKeyword == R.SpaceAfterTemplateKeyword &&
            SpaceBeforeAssignmentOperators == R.SpaceBeforeAssignmentOperators &&
            SpaceBeforeParens == R.SpaceBeforeParens &&
            SpaceInEmptyParentheses == R.SpaceInEmptyParentheses &&
            SpacesBeforeTrailingComments == R.SpacesBeforeTrailingComments &&
            SpacesInAngles == R.SpacesInAngles &&
            SpacesInContainerLiterals == R.SpacesInContainerLiterals &&
            SpacesInCStyleCastParentheses == R.SpacesInCStyleCastParentheses &&
            SpacesInParentheses == R.SpacesInParentheses &&

lib/Format/Format.cpp

static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("PenaltyBreakFirstLessLess",
                    Style.PenaltyBreakFirstLessLess);
     IO.mapOptional("PenaltyBreakString", Style.PenaltyBreakString);
     IO.mapOptional("PenaltyExcessCharacter", Style.PenaltyExcessCharacter);
     IO.mapOptional("PenaltyReturnTypeOnItsOwnLine",
                    Style.PenaltyReturnTypeOnItsOwnLine);
     IO.mapOptional("PointerAlignment", Style.PointerAlignment);
     IO.mapOptional("SpaceAfterCStyleCast", Style.SpaceAfterCStyleCast);
+    IO.mapOptional("SpaceAfterTemplateKeyword", Style.SpaceAfterTemplateKeyword);
     IO.mapOptional("SpaceBeforeAssignmentOperators",
                    Style.SpaceBeforeAssignmentOperators);
     IO.mapOptional("SpaceBeforeParens", Style.SpaceBeforeParens);
     IO.mapOptional("SpaceInEmptyParentheses", Style.SpaceInEmptyParentheses);
     IO.mapOptional("SpacesBeforeTrailingComments",
                    Style.SpacesBeforeTrailingComments);
     IO.mapOptional("SpacesInAngles", Style.SpacesInAngles);
     IO.mapOptional("SpacesInContainerLiterals",
FormatStyle getLLVMStyle() {
   LLVMStyle.Standard = FormatStyle::LS_Cpp11;
   LLVMStyle.UseTab = FormatStyle::UT_Never;
   LLVMStyle.SpacesInParentheses = false;
   LLVMStyle.SpacesInSquareBrackets = false;
   LLVMStyle.SpaceInEmptyParentheses = false;
   LLVMStyle.SpacesInContainerLiterals = true;
   LLVMStyle.SpacesInCStyleCastParentheses = false;
   LLVMStyle.SpaceAfterCStyleCast = false;
+  LLVMStyle.SpaceAfterTemplateKeyword = true;
   LLVMStyle.SpaceBeforeParens = FormatStyle::SBPO_ControlStatements;
   LLVMStyle.SpaceBeforeAssignmentOperators = true;
   LLVMStyle.SpacesInAngles = false;
 
   LLVMStyle.PenaltyBreakComment = 300;
   LLVMStyle.PenaltyBreakFirstLessLess = 120;
   LLVMStyle.PenaltyBreakString = 1000;
   LLVMStyle.PenaltyExcessCharacter = 1000000;

lib/Format/TokenAnnotator.cpp

bool TokenAnnotator::spaceRequiredBetween(const AnnotatedLine &Line,
   if (Left.is(tok::l_paren) || Right.is(tok::r_paren))
     return (Right.is(TT_CastRParen) ||
             (Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen)))
                ? Style.SpacesInCStyleCastParentheses
                : Style.SpacesInParentheses;
   if (Right.isOneOf(tok::semi, tok::comma))
     return false;
   if (Right.is(tok::less) &&
-      (Left.is(tok::kw_template) ||
+      ((Left.is(tok::kw_template) && Style.SpaceAfterTemplateKeyword) ||
        (Line.Type == LT_ObjCDecl && Style.ObjCSpaceBeforeProtocolList)))
     return true;
   if (Left.isOneOf(tok::exclaim, tok::tilde))
     return false;
   if (Left.is(tok::at) &&
       Right.isOneOf(tok::identifier, tok::string_literal, tok::char_constant,
                     tok::numeric_constant, tok::l_paren, tok::l_brace,
                     tok::kw_true, tok::kw_false))

unittests/Format/FormatTest.cpp

TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("template <class... Ts> void Foo(Ts... ts) { Foo(ts...); }");
   verifyFormat("template <class... Ts> void Foo(Ts *... ts) {}");
 
   FormatStyle PointersLeft = getLLVMStyle();
   PointersLeft.PointerAlignment = FormatStyle::PAS_Left;
   verifyFormat("template <class... Ts> void Foo(Ts*... ts) {}", PointersLeft);
 }
 
+TEST_F(FormatTest, SpaceAfterTemplate) {
+  FormatStyle Style = getLLVMStyle();
+  Style.SpaceAfterTemplateKeyword = false;
+  verifyFormat("template<> class Foo<int> {}", Style);
+  verifyFormat("template<> void Foo<int>() {}", Style);
+  verifyFormat("template<class... Ts> class Foo {}", Style);
+  verifyFormat("template<class... Ts> void Foo() {}", Style);
+  verifyFormat("template<typename T> class Foo {}", Style);
+  verifyFormat("template<typename T> void Foo() {}", Style);
+}
+
 TEST_F(FormatTest, AdaptivelyFormatsPointersAndReferences) {
   EXPECT_EQ("int *a;\n"
             "int *a;\n"
             "int *a;",
             format("int *a;\n"
                    "int* a;\n"
                    "int *a;",
                    getGoogleStyle()));