[AST] Print a<b<c>> without extra spaces in C++11 or later.

[sammccall]

Summary

It's not 1998 anymore.

[sammccall]

@kadircet sending this to you as I noticed it as a clangd hover bug :-) The highest impact is probably in diagnostic messages though.

AFAICT the state before this patch is:

• the type printer always printed the space
• the stmt printer calls into the type printer to print arg lists
• the decl printer never prints the space

The best, most consistent thing would be to also fix the decl printer to respect the setting. But I haven't done that in this patch. At least the default configuration (C++14) is now consistent between type/stmt/decl.

[sammccall]

update/move comment

[kadircet]

LGTM, thanks !

clang/unittests/AST/DeclPrinterTest.cpp

1161–1162

testing scheme here seems to be annoying, had to search for TestTemplateArgumentList8 for a pre-cxx11 case :D

but nothing much to do ...

[rnk]

We ran into three distinct issues with this change.

We updated the compiler and break some VS std::map visualizers:
https://crbug.com/1068394
I haven't 100% confirmed that this caused the issue, but looking at the code suggests that the names in our codeview output changed, which I would consider to be a regression. This should've been caught by clang's test suite. We already have codeview tests that try to ensure clang prints debug info names following MSVC's exact spacing, but apparently none broke, so this area was under-tested. I wonder if gdb or other DWARF consumers might be affected by this formatting change.

Two issues in the Chrome codebase where tests relied on the output of clang's diagnostics:
https://crbug.com/1064986
The compiler's diagnostic output isn't stable, so this is expected.

While I appreciate the effort towards modernization, I want to register that it has created work for folks, and this might come up again in six months during the next release. @tstellar @hans

[sammccall]

Sorry about the problems here, and thanks for letting me know...

In D76801#1989421, @rnk wrote:

We updated the compiler and break some VS std::map visualizers:
https://crbug.com/1068394
I haven't 100% confirmed that this caused the issue, but looking at the code suggests that the names in our codeview output changed, which I would consider to be a regression. This should've been caught by clang's test suite. We already have codeview tests that try to ensure clang prints debug info names following MSVC's exact spacing, but apparently none broke, so this area was under-tested. I wonder if gdb or other DWARF consumers might be affected by this formatting change.

I've got a sinking feeling that I misunderstood the implications of updating CodeGenCXX/debug-info-template-explicit-specialization.cpp and the Modules/*DebugInfo.cpp tests.
I assumed that these were human-readable names, not things that tools rely on. As you say maybe the dwarf changes broke things.
I don't really know much about debug info, @dblaikie do you think the DWARF changes in those tests are safe? If not, should I be documenting/mitigating this or trying to undo it?

Regarding CodeView it sounds like we do need to undo this change. PrintingPolicy has:

/// Use whitespace and punctuation like MSVC does. In particular, this prints
/// anonymous namespaces as `anonymous namespace' and does not insert spaces
/// after template arguments.
unsigned MSVCFormatting : 1;

and this is set in CGDebugInfo::getPrintingPolicy() in CodeView mode.

That seems like the right knob to change this behavior.
I'm not sure I know enough to write the codeview test, but I'll give it a shot and send that to you.

Two issues in the Chrome codebase where tests relied on the output of clang's diagnostics:
https://crbug.com/1064986
The compiler's diagnostic output isn't stable, so this is expected.

Yeah, obviously this changed a bunch of clang's own diagnostics tests too.
I'm not sure there's much to be done about this - even with perfect knowledge of such downstream tests, I don't think shying away from marginal improvements in diagnostics would be a great tradeoff.
Sorry about the churn though :-(

[rnk]

In D76801#1989641, @sammccall wrote:

I've got a sinking feeling that I misunderstood the implications of updating CodeGenCXX/debug-info-template-explicit-specialization.cpp and the Modules/*DebugInfo.cpp tests.
I assumed that these were human-readable names, not things that tools rely on. As you say maybe the dwarf changes broke things.
I don't really know much about debug info, @dblaikie do you think the DWARF changes in those tests are safe? If not, should I be documenting/mitigating this or trying to undo it?

Regarding CodeView it sounds like we do need to undo this change. PrintingPolicy has:

/// Use whitespace and punctuation like MSVC does. In particular, this prints
/// anonymous namespaces as `anonymous namespace' and does not insert spaces
/// after template arguments.
unsigned MSVCFormatting : 1;

and this is set in CGDebugInfo::getPrintingPolicy() in CodeView mode.

That seems like the right knob to change this behavior.
I'm not sure I know enough to write the codeview test, but I'll give it a shot and send that to you.

Yep, that sounds like the right fix. I was imagining some policy method useMSVCFormatting that flips both options together.

Hang on, I may have been too quick. We *do* have a test for this, at the end of clang/test/CodeGenCXX/debug-info-codeview-display-names.cpp:
https://github.com/llvm/llvm-project/blob/f8452ddfcc3336e42544a35481507f0b3bae423e/clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp#L98

The test passes for me locally, although I'm not sure why.

I would leave things a bit longer to give @amccarth more time to investigate and confirm. Thanks for the offer to help, though.

[sammccall]

In D76801#1989718, @rnk wrote:

Hang on, I may have been too quick. We *do* have a test for this, at the end of clang/test/CodeGenCXX/debug-info-codeview-display-names.cpp:
https://github.com/llvm/llvm-project/blob/f8452ddfcc3336e42544a35481507f0b3bae423e/clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp#L98

The test passes for me locally, although I'm not sure why.

After this patch the default depends on the language version, and that test specifies c++98 :-(

I would leave things a bit longer to give @amccarth more time to investigate and confirm. Thanks for the offer to help, though.

Sure thing, let me know if it's useful for me to pick this up. I'm sure the debugging was the worst of it though, sorry.

[dblaikie]

In D76801#1989641, @sammccall wrote:

Sorry about the problems here, and thanks for letting me know...

In D76801#1989421, @rnk wrote:

We updated the compiler and break some VS std::map visualizers:
https://crbug.com/1068394
I haven't 100% confirmed that this caused the issue, but looking at the code suggests that the names in our codeview output changed, which I would consider to be a regression. This should've been caught by clang's test suite. We already have codeview tests that try to ensure clang prints debug info names following MSVC's exact spacing, but apparently none broke, so this area was under-tested. I wonder if gdb or other DWARF consumers might be affected by this formatting change.

I've got a sinking feeling that I misunderstood the implications of updating CodeGenCXX/debug-info-template-explicit-specialization.cpp and the Modules/*DebugInfo.cpp tests.
I assumed that these were human-readable names, not things that tools rely on. As you say maybe the dwarf changes broke things.
I don't really know much about debug info, @dblaikie do you think the DWARF changes in those tests are safe? If not, should I be documenting/mitigating this or trying to undo it?

( @aprantl @JDevlieghere @probinson @cmtice @tamur @labath )

In general DWARF doesn't specify this at all. In reality, at least GDB does some fuzzy matching - I don't know about LLDB and SCE (Sony's debugger).

GDB's fuzzy matching seems sufficient to make this work/not be a problem here.

Here's one example of testing that. Compile these two files with different compilers (either Clang<with this patch>+GCC, or Clang<with>+Clang<without>):

template<typename T>
struct tmpl {
  int member = 42;
};

const tmpl<tmpl<int>> *get_obj() {
  static tmpl<tmpl<int>> t;
  return &t;
}
int get_mem(const tmpl<tmpl<int>> *t) {
  return t->member;
}

template<typename T>
struct tmpl;

const tmpl<tmpl<int>> *get_obj();
int get_mem(const tmpl<tmpl<int>> *t);

int main() {
  const tmpl<tmpl<int>> *x = get_obj();
  return get_mem(x);
}

Then launch that in a debugger & stop in main, print the type of 'x' - it should include the int member named 'member':

type = const struct tmpl<tmpl<int> > [with T = tmpl<int>] {
    int member;
} *

If the debugger can't associate the type in the two files together, then the type of 'x' would print out as an incomplete type (you can test this by compiling the first file without debug info):

type = const struct tmpl<tmpl<int>> {
    <incomplete type>
} *

[labath]

David's example does work with gdb without -Wl,--gdb-index (the member variable is shown), presumably due to the aforementioned fuzzy matching. However, it does not work if gdb-index is enabled, nor with lldb (as lldb is always very index-oriented and assumes equality everywhere). That is definitely not ideal, though I'm not sure that means about this patch. This is definitely not the only difference in the formatting of DW_AT_names of templates. For example, template<typename T> operator<<(T, T) will come out as operator<< <A> with gcc, but as operator<<<A> with clang (with or without this patch).
OTOH, differences in type names are more likely to cause problems than is the case for functions/operators.

[dblaikie]

In D76801#1991904, @labath wrote:

David's example does work with gdb without -Wl,--gdb-index (the member variable is shown), presumably due to the aforementioned fuzzy matching. However, it does not work if gdb-index is enabled, nor with lldb (as lldb is always very index-oriented and assumes equality everywhere). That is definitely not ideal, though I'm not sure that means about this patch. This is definitely not the only difference in the formatting of DW_AT_names of templates. For example, template<typename T> operator<<(T, T) will come out as operator<< <A> with gcc, but as operator<<<A> with clang (with or without this patch).
OTOH, differences in type names are more likely to cause problems than is the case for functions/operators.

That is concerning. Any idea if that's only with lld's gdb-indexx implementation, or also gold's? This isn't the only naming divergence between GCC and Clang, though, so if gdb-index doesn't support any divergence, that's a problem... (I think non-type template parameters diverge too, perhaps? well, GCC 6 used to print "foo<3u>" (for an unsigned non-type template parameter) and clang/more recent GCC versions just use "foo<3>" now, for instance - enums, GCC uses foo<(EnumType)0> whereas Clang uses foo<enumeratorName> if it's named and foo<3> if it's unnamed))

Differences in function names could manifest as differences in type names - due to local types nested inside functions, but they're less likely/highly unlikely to have a decl/def resolution between CUs, so maybe nested types are less problematic.

[labath]

In D76801#1993337, @dblaikie wrote:

In D76801#1991904, @labath wrote:

David's example does work with gdb without -Wl,--gdb-index (the member variable is shown), presumably due to the aforementioned fuzzy matching. However, it does not work if gdb-index is enabled, nor with lldb (as lldb is always very index-oriented and assumes equality everywhere). That is definitely not ideal, though I'm not sure that means about this patch. This is definitely not the only difference in the formatting of DW_AT_names of templates. For example, template<typename T> operator<<(T, T) will come out as operator<< <A> with gcc, but as operator<<<A> with clang (with or without this patch).
OTOH, differences in type names are more likely to cause problems than is the case for functions/operators.

That is concerning. Any idea if that's only with lld's gdb-indexx implementation, or also gold's?

I was using gold for my initial test. However, the same thing happens with lld too...

This isn't the only naming divergence between GCC and Clang, though, so if gdb-index doesn't support any divergence, that's a problem...

It becomes a gdb-index problem because with an index the debugger will do a (hashed?) string lookup and expect the string to be there. If the strings differ, the lookup won't find anything. In the no-index scenario, the debugger has to trawl the debug info itself, and so it has some opportunities to do fuzzy matching.

[dblaikie]

In D76801#1994003, @labath wrote:

In D76801#1993337, @dblaikie wrote:

In D76801#1991904, @labath wrote:

David's example does work with gdb without -Wl,--gdb-index (the member variable is shown), presumably due to the aforementioned fuzzy matching. However, it does not work if gdb-index is enabled, nor with lldb (as lldb is always very index-oriented and assumes equality everywhere). That is definitely not ideal, though I'm not sure that means about this patch. This is definitely not the only difference in the formatting of DW_AT_names of templates. For example, template<typename T> operator<<(T, T) will come out as operator<< <A> with gcc, but as operator<<<A> with clang (with or without this patch).
OTOH, differences in type names are more likely to cause problems than is the case for functions/operators.

That is concerning. Any idea if that's only with lld's gdb-indexx implementation, or also gold's?

I was using gold for my initial test. However, the same thing happens with lld too...

Good to know! Thanks for checking!

This isn't the only naming divergence between GCC and Clang, though, so if gdb-index doesn't support any divergence, that's a problem...

It becomes a gdb-index problem because with an index the debugger will do a (hashed?) string lookup and expect the string to be there. If the strings differ, the lookup won't find anything. In the no-index scenario, the debugger has to trawl the debug info itself, and so it has some opportunities to do fuzzy matching.

That surprises me a bit - given that one of the things debuggers provide is autocomplete (I'm unlikely to write out a type name exactly as the debug info contains it - if two compilers can't agree, it's much less likely that all users will agree with any compiler rendering), which I'd have thought would be facilitated by the index too - in which case lookup via exact match wouldn't be viable, you'd still want a way to list anything with a matching substring (or at least prefix), etc. Which could help facilitate lookup fuzzy matching like in this sort of case.

[labath]

In D76801#1995058, @dblaikie wrote:

It becomes a gdb-index problem because with an index the debugger will do a (hashed?) string lookup and expect the string to be there. If the strings differ, the lookup won't find anything. In the no-index scenario, the debugger has to trawl the debug info itself, and so it has some opportunities to do fuzzy matching.

That surprises me a bit - given that one of the things debuggers provide is autocomplete (I'm unlikely to write out a type name exactly as the debug info contains it - if two compilers can't agree, it's much less likely that all users will agree with any compiler rendering), which I'd have thought would be facilitated by the index too - in which case lookup via exact match wouldn't be viable, you'd still want a way to list anything with a matching substring (or at least prefix), etc. Which could help facilitate lookup fuzzy matching like in this sort of case.

That is kind of true, and I don't really have a definitive reply to that. I suppose there is a difference between the lookups done for type completion and those done e.g. in expression evaluation. The latter are probably more frequent and are assumed to be correct. Maybe they shouldn't be, but in that cases, then there would probably be no use for the hash tables in indexes (I am not very familiar with the gdb index, but I know it has hash tables similar to debug_names/apple_names). I don't know what gdb does for tab completion, but it probably bypasses the hash table (though the index could still be useful even then as it has a concise list of all strings in the debug info), or it gets the list of strings-to-complete from a completely different source (demangled function names?).

Tab completion is always a bit dodgy. E.g., in your example ptype tmpl<TAB> completes to ptype tmpl<tmpl<int>>, but then running that produces an error: No symbol "tmpl" in current context.

In lldb, tab completion in expressions works by hooking into the regular clang tab-completion machinery used by editors. The up- and down-side of that is that it uses the same code path used for actual expression evaluation -- i.e. all the types will be looked up the same (exact) way.

Speaking of templates and indexes, the thing we would really like in lldb would be to have just the bare names of templated class in the indexes -- that way we could reliably look up all instantiations of a template and do the filtering ourselves. However, this runs afoul of the dwarf specification, which says that the index names should match the DW_AT_names of relevant DIEs (and these contain the template arguments for other reasons...). This means that currently we have outstanding issues when looking up templated types, but we haven't really figured out what to do about that...

[dblaikie]

In D76801#1996376, @labath wrote:

In D76801#1995058, @dblaikie wrote:

It becomes a gdb-index problem because with an index the debugger will do a (hashed?) string lookup and expect the string to be there. If the strings differ, the lookup won't find anything. In the no-index scenario, the debugger has to trawl the debug info itself, and so it has some opportunities to do fuzzy matching.

That surprises me a bit - given that one of the things debuggers provide is autocomplete (I'm unlikely to write out a type name exactly as the debug info contains it - if two compilers can't agree, it's much less likely that all users will agree with any compiler rendering), which I'd have thought would be facilitated by the index too - in which case lookup via exact match wouldn't be viable, you'd still want a way to list anything with a matching substring (or at least prefix), etc. Which could help facilitate lookup fuzzy matching like in this sort of case.

That is kind of true, and I don't really have a definitive reply to that. I suppose there is a difference between the lookups done for type completion and those done e.g. in expression evaluation. The latter are probably more frequent and are assumed to be correct. Maybe they shouldn't be, but in that cases, then there would probably be no use for the hash tables in indexes (I am not very familiar with the gdb index, but I know it has hash tables similar to debug_names/apple_names). I don't know what gdb does for tab completion, but it probably bypasses the hash table (though the index could still be useful even then as it has a concise list of all strings in the debug info), or it gets the list of strings-to-complete from a completely different source (demangled function names?).

Tab completion is always a bit dodgy. E.g., in your example ptype tmpl<TAB> completes to ptype tmpl<tmpl<int>>, but then running that produces an error: No symbol "tmpl" in current context.

In lldb, tab completion in expressions works by hooking into the regular clang tab-completion machinery used by editors. The up- and down-side of that is that it uses the same code path used for actual expression evaluation -- i.e. all the types will be looked up the same (exact) way.

Speaking of templates and indexes, the thing we would really like in lldb would be to have just the bare names of templated class in the indexes -- that way we could reliably look up all instantiations of a template and do the filtering ourselves. However, this runs afoul of the dwarf specification, which says that the index names should match the DW_AT_names of relevant DIEs (and these contain the template arguments for other reasons...). This means that currently we have outstanding issues when looking up templated types, but we haven't really figured out what to do about that...

Yeah, points all taken - as for this actual issue... I'm kind of inclined to say "hey, our template names already diverge somewhat - and this divergence is in the realm of acceptable by gdb (without an index) so... *thumbs up*/let's stick with it" & as I think you mentioned earlier, this is more a problem for the index support, than for the debug info producer. I don't think it's a reasonable goal that Clang & GCC produce /exactly/ the same names for templates like this... I mean, we /could/ try, but I don't think it's worthwhile (especially given that gdb's got support intended to do fuzzy matching/allow some divergence)

[rnk]

Thanks David, I'm comfortable with that stance for DWARF.

I know @amccarth is looking into the recent VS visualizer issue, and I would like him to confirm if it was this change or not when he gets a chance.

[labath]

In D76801#1997451, @dblaikie wrote:

Yeah, points all taken - as for this actual issue... I'm kind of inclined to say "hey, our template names already diverge somewhat - and this divergence is in the realm of acceptable by gdb (without an index) so... *thumbs up*/let's stick with it"

Another interesting aspect here is that the DW_AT_name outputs depend on the c++ standard versions used. This means we could get mismatches even with the same compiler if some compile units use -std=c++98, and others -std>=c++11 (hardly a recommended practice but it does work if one knows what he is doing). Compatibility with another compiler is one thing, but maybe self-compatibility is more important (and easier to achieve) ?

One way to achieve that would be by printing all type names in c++98 mode, which (IIUC) is the same thing as what the windows folks are requesting..

[dblaikie]

In D76801#2005264, @labath wrote:

In D76801#1997451, @dblaikie wrote:

Yeah, points all taken - as for this actual issue... I'm kind of inclined to say "hey, our template names already diverge somewhat - and this divergence is in the realm of acceptable by gdb (without an index) so... *thumbs up*/let's stick with it"

Another interesting aspect here is that the DW_AT_name outputs depend on the c++ standard versions used.

Yeah, I find that at least "weird", though not necessarily wrong.

This means we could get mismatches even with the same compiler if some compile units use -std=c++98, and others -std>=c++11 (hardly a recommended practice but it does work if one knows what he is doing). Compatibility with another compiler is one thing, but maybe self-compatibility is more important (and easier to achieve) ?

Yeah, I don't disagree with that - again, not quite sure I'd say it goes as far as "wrong" (I mean, DWARF doesn't spec this - so wrongness in our own judgment, not any authoritative sense) but yeah, perhaps insufficiently motivated quirkiness.

One way to achieve that would be by printing all type names in c++98 mode, which (IIUC) is the same thing as what the windows folks are requesting..

Fair enough - I wouldn't object to that change being made & just having it the same for MSVC and DWARF in this case. (it's a /bit/ less good for C++11 and above users to get names with the extra space, but seems minor enough perhaps not to bother trying to preserve it given the complicaitons)

[dyung]

Hi, we noticed an issue with the GDB test suite that was bisected back to this change and I have put the details in PR46052. Can you take a look?

[sammccall]

In D76801#2052270, @dyung wrote:

Hi, we noticed an issue with the GDB test suite that was bisected back to this change and I have put the details in PR46052. Can you take a look?

Sorry this never got clearly resolved.
I think the conclusion is while this is all best-effort, we might as well undo the debuginfo changes here. Sent D80554

clang-tools-extra/clangd/unittests/HoverTests.cpp

const std::function<void(HoverInfo &)> ExpectedBuilder;
           template <class T> struct cls {};
           cls<cls<cls<int>>> [[fo^o]];
           )cpp",
           [](HoverInfo &HI) {
             HI.Definition = "cls<cls<cls<int>>> foo";
             HI.Kind = index::SymbolKind::Variable;
             HI.NamespaceScope = "";
             HI.Name = "foo";
-            HI.Type = "cls<cls<cls<int> > >";
+            HI.Type = "cls<cls<cls<int>>>";
             HI.Value = "{}";
           }},
       {
           R"cpp(// type of nested templates.
           template <class T> struct cls {};
           [[cl^s]]<cls<cls<int>>> foo;
           )cpp",
           [](HoverInfo &HI) {
             HI.Definition = "template <> struct cls<cls<cls<int>>> {}";
             HI.Kind = index::SymbolKind::Struct;
             HI.NamespaceScope = "";
-            HI.Name = "cls<cls<cls<int> > >";
+            HI.Name = "cls<cls<cls<int>>>";
             HI.Documentation = "type of nested templates.";
           }},
       {
           R"cpp(// type with decltype
           int a;
           decltype(a) [[b^]] = a;)cpp",
           [](HoverInfo &HI) {
             HI.Definition = "decltype(a) b = a";

clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp

 // CHECK-FIXES-NEXT: using Q3_p = Q3_t*;
 
 typedef Q<T{0 < 0}.b> Q3_t;
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
 // CHECK-FIXES: using Q3_t = Q<T{0 < 0}.b>;
 
 typedef TwoArgTemplate<TwoArgTemplate<int, Q<T{0 < 0}.b> >, S<(0 < 0), Q<b[0 < 0]> > > Nested_t;
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
-// CHECK-FIXES: using Nested_t = TwoArgTemplate<TwoArgTemplate<int, Q<T{0 < 0}.b> >, S<(0 < 0), Q<b[0 < 0]> > >;
+// CHECK-FIXES: using Nested_t = TwoArgTemplate<TwoArgTemplate<int, Q<T{0 < 0}.b>>, S<(0 < 0), Q<b[0 < 0]>>>;
 
 template <typename... Args>
 class Variadic {};
 
 typedef Variadic<Variadic<int, bool, Q<T{0 < 0}.b> >, S<(0 < 0), Variadic<Q<b[0 < 0]> > > > Variadic_t;
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
-// CHECK-FIXES: using Variadic_t = Variadic<Variadic<int, bool, Q<T{0 < 0}.b> >, S<(0 < 0), Variadic<Q<b[0 < 0]> > > >
+// CHECK-FIXES: using Variadic_t = Variadic<Variadic<int, bool, Q<T{0 < 0}.b>>, S<(0 < 0), Variadic<Q<b[0 < 0]>>>>
 
 typedef Variadic<Variadic<int, bool, Q<T{0 < 0}.b> >, S<(0 < 0), Variadic<Q<b[0 < 0]> > > > Variadic_t, *Variadic_p;
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
 // CHECK-MESSAGES: :[[@LINE-2]]:103: warning: use 'using' instead of 'typedef'
-// CHECK-FIXES: using Variadic_t = Variadic<Variadic<int, bool, Q<T{0 < 0}.b> >, S<(0 < 0), Variadic<Q<b[0 < 0]> > > >;
+// CHECK-FIXES: using Variadic_t = Variadic<Variadic<int, bool, Q<T{0 < 0}.b>>, S<(0 < 0), Variadic<Q<b[0 < 0]>>>>;
 // CHECK-FIXES-NEXT: using Variadic_p = Variadic_t*;
 
 typedef struct { int a; } R_t, *R_p;
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
 // CHECK-MESSAGES: :[[@LINE-2]]:30: warning: use 'using' instead of 'typedef'
 // CHECK-FIXES: using R_t = struct { int a; };
 // CHECK-FIXES-NEXT: using R_p = R_t*;
 

clang/include/clang/AST/PrettyPrinter.h

PrintingPolicy(const LangOptions &LO)
       : Indentation(2), SuppressSpecifiers(false),
         SuppressTagKeyword(LO.CPlusPlus), IncludeTagDefinition(false),
         SuppressScope(false), SuppressUnwrittenScope(false),
         SuppressInitializers(false), ConstantArraySizeAsWritten(false),
         AnonymousTagLocations(true), SuppressStrongLifetime(false),
         SuppressLifetimeQualifiers(false),
         SuppressTemplateArgsInCXXConstructors(false), Bool(LO.Bool),
         Restrict(LO.C99), Alignof(LO.CPlusPlus11), UnderscoreAlignof(LO.C11),
-        UseVoidForZeroParams(!LO.CPlusPlus), TerseOutput(false),
+        UseVoidForZeroParams(!LO.CPlusPlus),
+        SplitTemplateClosers(!LO.CPlusPlus11), TerseOutput(false),
         PolishForDeclaration(false), Half(LO.Half),
         MSWChar(LO.MicrosoftExt && !LO.WChar), IncludeNewlines(true),
         MSVCFormatting(false), ConstantsAsWritten(false),
         SuppressImplicitBase(false), FullyQualifiedName(false),
         PrintCanonicalTypes(false) {}
 
   /// Adjust this printing policy for cases where it's known that we're
   /// printing C++ code (for instance, if AST dumping reaches a C++-only
struct PrintingPolicy {
 
   /// Whether we can use '_Alignof' rather than '__alignof'.
   unsigned UnderscoreAlignof : 1;
 
   /// Whether we should use '(void)' rather than '()' for a function prototype
   /// with zero parameters.
   unsigned UseVoidForZeroParams : 1;
 
+  /// Whether nested templates must be closed like a<b<c> > rather than a<b<c>>.
+  unsigned SplitTemplateClosers : 1;
+
   /// Provide a 'terse' output.
   ///
   /// For example, in this mode we don't print function bodies, class members,
   /// declarations inside namespaces etc.  Effectively, this should print
   /// only the requested declaration.
   unsigned TerseOutput : 1;
 
   /// When true, do certain refinement needed for producing proper declaration

clang/lib/AST/TypePrinter.cpp

for (const auto &Arg : Args) {
     // If this is the first argument and its string representation
     // begins with the global scope specifier ('::foo'), add a space
     // to avoid printing the diagraph '<:'.
     if (FirstArg && !ArgString.empty() && ArgString[0] == ':')
       OS << ' ';
 
     OS << ArgString;
 
-    NeedSpace = (!ArgString.empty() && ArgString.back() == '>');
+    // If the last character of our string is '>', add another space to
+    // keep the two '>''s separate tokens.
+    NeedSpace = Policy.SplitTemplateClosers && !ArgString.empty() &&
+                ArgString.back() == '>';
     FirstArg = false;
   }
 
-  // If the last character of our string is '>', add another space to
-  // keep the two '>''s separate tokens. We don't *have* to do this in
-  // C++0x, but it's still good hygiene.
   if (NeedSpace)
     OS << ' ';
 
   if (!SkipBrackets)
     OS << '>';
 }
 
 void clang::printTemplateArgumentList(raw_ostream &OS,

clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp

 using r1i2 = r1<int>; // expected-error{{constraints not satisfied for class template 'r1' [with T = int]}}
 using r1i3 = r1<C>; // expected-error{{constraints not satisfied for class template 'r1' [with T = C]}}
 using r1i4 = r1<D>; // expected-error{{constraints not satisfied for class template 'r1' [with T = D]}}
 
 template<typename T> struct invalid { typename T::type x; };
 // expected-error@-1 {{typename specifier refers to non-type member 'type' in 'D'}}
 using r1i5 = r1<invalid<D>>;
 // expected-error@-1 {{constraints not satisfied for class template 'r1' [with T = invalid<D>]}}
-// expected-note@-2 {{while checking constraint satisfaction for template 'r1<invalid<D> >' required here}}
+// expected-note@-2 {{while checking constraint satisfaction for template 'r1<invalid<D>>' required here}}
 
 // mismatching template arguments
 
 template<typename... Ts> requires requires { typename identity<Ts...>; } // expected-note{{because 'typename identity<Ts...>' would be invalid: too many template arguments for class template 'identity'}}
 struct r2 {};
 
 using r2i1 = r2<int>;
 using r2i2 = r2<void>;
namespace std_example {
   template<C2 T> struct C2_check {};
   // expected-note@-1 {{because 'std_example::has_inner' does not satisfy 'C2'}}
   template<C3 T> struct C3_check {};
   // expected-note@-1 {{because 'void' does not satisfy 'C3'}}
   using c1 = C1_check<int>; // expected-error{{constraints not satisfied for class template 'C1_check' [with T = int]}}
   using c2 = C1_check<has_type>; // expected-error{{constraints not satisfied for class template 'C1_check' [with T = std_example::has_type]}}
   using c3 = C2_check<has_inner>; // expected-error{{constraints not satisfied for class template 'C2_check' [with T = std_example::has_inner]}}
   using c4 = C3_check<void>; // expected-error{{constraints not satisfied for class template 'C3_check' [with T = void]}}
-}
+}
 

clang/test/CXX/temp/temp.arg/temp.arg.template/p3-0x.cpp

 // RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
 
 template <class T> struct eval; // expected-note 3{{template is declared here}}
 
 template <template <class, class...> class TT, class T1, class... Rest> 
 struct eval<TT<T1, Rest...>> { };
 
 template <class T1> struct A; 
 template <class T1, class T2> struct B; 
 template <int N> struct C; 
 template <class T1, int N> struct D; 
 template <class T1, class T2, int N = 17> struct E;
 
 eval<A<int>> eA;
 eval<B<int, float>> eB;
-eval<C<17>> eC; // expected-error{{implicit instantiation of undefined template 'eval<C<17> >'}}
-eval<D<int, 17>> eD; // expected-error{{implicit instantiation of undefined template 'eval<D<int, 17> >'}}
-eval<E<int, float>> eE; // expected-error{{implicit instantiation of undefined template 'eval<E<int, float, 17> >}}
+eval<C<17>> eC; // expected-error{{implicit instantiation of undefined template 'eval<C<17>>'}}
+eval<D<int, 17>> eD; // expected-error{{implicit instantiation of undefined template 'eval<D<int, 17>>'}}
+eval<E<int, float>> eE; // expected-error{{implicit instantiation of undefined template 'eval<E<int, float, 17>>}}
 
 template<template <int ...N> class TT> struct X0 { }; // expected-note{{previous non-type template parameter with type 'int' is here}}
 template<int I, int J, int ...Rest> struct X0a;
 template<int ...Rest> struct X0b;
 template<int I, long J> struct X0c; // expected-note{{template non-type parameter has a different type 'long' in template argument}}
 
 X0<X0a> inst_x0a;
 X0<X0b> inst_x0b;

clang/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp

 };
 extern template class j<int>;
 j<int> jj;
 template <typename T>
 struct j_wrap {
 };
 j_wrap<j<int>> j_wrap_j;
 // CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "j<int, int>"
-// CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "j_wrap<j<int, int> >"
+// CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "j_wrap<j<int, int>>"
 
 template <typename T>
 struct k {
 };
 template <>
 struct k<int>;
 template struct k<int>;
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type, name: "k<int>"
 
 // CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "b<int>"
 // CHECK-NOT: DIFlagFwdDecl
 // CHECK-SAME: ){{$}}

clang/test/Misc/diag-aka-types.cpp

 void test() {
  helper(&ns::str::method); // expected-error{{no matching function for call to 'helper'}}
 }
 
 template <typename T>
 class A {};
 
 int a1 = A<decltype(1 + 2)>(); // expected-error{{no viable conversion from 'A<decltype(1 + 2)>' (aka 'A<int>') to 'int'}}
-int a2 = A<A<decltype(1 + 2)>>(); // expected-error{{no viable conversion from 'A<A<decltype(1 + 2)> >' (aka 'A<A<int> >') to 'int'}}
+int a2 = A<A<decltype(1 + 2)>>(); // expected-error{{no viable conversion from 'A<A<decltype(1 + 2)>>' (aka 'A<A<int>>') to 'int'}}
 int a3 = A<__typeof(1 + 2)>(); // expected-error{{no viable conversion from 'A<typeof (1 + 2)>' (aka 'A<int>') to 'int'}}
-int a4 = A<A<__typeof(1 + 2)>>(); // expected-error{{no viable conversion from 'A<A<typeof (1 + 2)> >' (aka 'A<A<int> >') to 'int'}}
+int a4 = A<A<__typeof(1 + 2)>>(); // expected-error{{no viable conversion from 'A<A<typeof (1 + 2)>>' (aka 'A<A<int>>') to 'int'}}
 
 using B = A<decltype(1+2)>;
 int a5 = B(); // expected-error{{no viable conversion from 'B' (aka 'A<int>') to 'int'}}
 
 decltype(void()) (&f1)() = 0; // expected-error{{non-const lvalue reference to type 'decltype(void()) ()' (aka 'void ()') cannot bind to a temporary of type 'int'}}
 decltype(void()) (&f2)(int) = 0; // expected-error{{non-const lvalue reference to type 'decltype(void()) (int)' (aka 'void (int)') cannot bind to a temporary of type 'int'}}
 void (&f3)(decltype(1 + 2)) = 0; // expected-error{{non-const lvalue reference to type 'void (decltype(1 + 2))' (aka 'void (int)') cannot bind to a temporary of type 'int'}}
 decltype(1+2) (&f4)(double, decltype(1 + 2)) = 0; // expected-error{{non-const lvalue reference to type 'decltype(1 + 2) (double, decltype(1 + 2))' (aka 'int (double, int)') cannot bind to a temporary of type 'int'}}
 auto (&f5)() -> decltype(1+2) = 0; // expected-error{{non-const lvalue reference to type 'auto () -> decltype(1 + 2)' (aka 'auto () -> int') cannot bind to a temporary of type 'int'}}

clang/test/Modules/ExtDebugInfo.cpp

 // CHECK-SAME:             flags: DIFlagFwdDecl,
 // CHECK-SAME:             identifier:  "_ZTSN8DebugCXX4EnumE")
 
 // CHECK: ![[NS]] = !DINamespace(name: "DebugCXX", scope: ![[MOD:[0-9]+]])
 // CHECK: ![[MOD]] = !DIModule(scope: null, name: {{.*}}DebugCXX
 
 // This type is not anchored in the module by an explicit template instantiation.
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<long, DebugCXX::traits<long> >",
+// CHECK-SAME:             name: "Template<long, DebugCXX::traits<long>>",
 // CHECK-SAME:             scope: ![[NS]],
 // CHECK-SAME:             elements:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIlNS_6traitsIlEEEE")
 
 // This type is anchored in the module by an explicit template instantiation.
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<int, DebugCXX::traits<int> >",
+// CHECK-SAME:             name: "Template<int, DebugCXX::traits<int>>",
 // CHECK-SAME:             scope: ![[NS]],
 // CHECK-SAME:             flags: DIFlagFwdDecl,
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIiNS_6traitsIiEEEE")
 
 // This type isn't, however, even with standalone non-module debug info this
 // type is a forward declaration.
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type, name: "traits<int>",
 
 // This one isn't.
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<float, DebugCXX::traits<float> >",
+// CHECK-SAME:             name: "Template<float, DebugCXX::traits<float>>",
 // CHECK-SAME:             scope: ![[NS]],
 // CHECK-SAME:             elements:
 // CHECK-SAME:             templateParams:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIfNS_6traitsIfEEEE")
 
 // This type is anchored in the module by an explicit template instantiation.
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "traits<float>",
 // CHECK-SAME:             flags: DIFlagFwdDecl,

clang/test/Modules/ModuleDebugInfo.cpp

 // CHECK-SAME:             templateParams:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX1AIJvEEE")
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Struct"
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX6StructE")
 
 // This type is anchored by an explicit template instantiation.
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<int, DebugCXX::traits<int> >"
+// CHECK-SAME:             name: "Template<int, DebugCXX::traits<int>>"
 // CHECK-SAME:             elements:
 // CHECK-SAME:             templateParams:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIiNS_6traitsIiEEEE")
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "traits<int>"
 // CHECK-SAME:             flags: DIFlagFwdDecl
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX6traitsIiEE")
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "traits<float>"
 // CHECK-SAME:             elements:
 // CHECK-SAME:             templateParams:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX6traitsIfEE")
 
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<long, DebugCXX::traits<long> >"
+// CHECK-SAME:             name: "Template<long, DebugCXX::traits<long>>"
 // CHECK-SAME:             elements:
 // CHECK-SAME:             templateParams:
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIlNS_6traitsIlEEEE")
 
 // CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "FloatInstantiation"
 // no mangled name here yet.
 
 // CHECK: !DICompositeType(tag: DW_TAG_class_type,
-// CHECK-SAME:             name: "Template<float, DebugCXX::traits<float> >"
+// CHECK-SAME:             name: "Template<float, DebugCXX::traits<float>>"
 // CHECK-SAME:             flags: DIFlagFwdDecl
 // CHECK-SAME:             identifier: "_ZTSN8DebugCXX8TemplateIfNS_6traitsIfEEEE")
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Virtual"
 // CHECK-SAME:             elements:
 // CHECK-SAME:             identifier: "_ZTS7Virtual")
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "_vptr$Virtual"
 

clang/test/OpenMP/distribute_parallel_for_private_messages.cpp

#pragma omp distribute parallel for private(i)
   static int m;
 #pragma omp target
 #pragma omp teams
 #pragma omp distribute parallel for private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/distribute_parallel_for_simd_private_messages.cpp

#pragma omp distribute parallel for simd private(i)
   static int m;
 #pragma omp target
 #pragma omp teams
 #pragma omp distribute parallel for simd private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/distribute_simd_private_messages.cpp

#pragma omp distribute simd private(i)
   static int m;
 #pragma omp target
 #pragma omp teams
 #pragma omp distribute simd private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/for_private_messages.cpp

#pragma omp for private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp for private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/for_simd_private_messages.cpp

#pragma omp for simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp for simd private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/master_taskloop_private_messages.cpp

#pragma omp master taskloop private(i, z)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp master taskloop private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/master_taskloop_simd_private_messages.cpp

#pragma omp master taskloop simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp master taskloop simd private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_for_private_messages.cpp

#pragma omp parallel for private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp parallel for private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_for_simd_private_messages.cpp

#pragma omp parallel for simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp parallel for simd private(m) // OK
   for (int k = 0; k < argc; ++k)
     m = k + 3;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_master_private_messages.cpp

#pragma omp parallel master private(i)
   }
   static int m;
 #pragma omp parallel master private(m)
   {
     foo();
   }
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_master_taskloop_private_messages.cpp

#pragma omp parallel master taskloop private(i, z)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp parallel master taskloop private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_master_taskloop_simd_private_messages.cpp

#pragma omp parallel master taskloop simd private(i, z)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp parallel master taskloop simd private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/parallel_sections_private_messages.cpp

#pragma omp parallel sections private(i)
   }
   static int m;
 #pragma omp parallel sections private(m)
   {
     foo();
   }
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/sections_private_messages.cpp

#pragma omp sections private(i)
   }
   static int m;
 #pragma omp sections private(m)
   {
     foo();
   }
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/simd_private_messages.cpp

int main(int argc, char **argv) {
   #pragma omp parallel shared(i)
   #pragma omp parallel private(i)
   #pragma omp simd private(j)
   for (int k = 0; k < argc; ++k) ++k;
   #pragma omp simd private(i)
   for (int k = 0; k < argc; ++k) ++k;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/single_private_messages.cpp

#pragma omp single private(j)
   foo();
 #pragma omp single private(i)
   foo();
   static int m;
 #pragma omp single private(m) // OK
   foo();
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/target_firstprivate_messages.cpp

 #pragma omp target firstprivate(i)
   {}
   static int si;
 #pragma omp target firstprivate(si) // OK
   {}
 #pragma omp target map(i) firstprivate(i) // expected-error {{firstprivate variable cannot be in a map clause in '#pragma omp target' directive}}
   {}
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/target_parallel_for_private_messages.cpp

#pragma omp target parallel for private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp target parallel for private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/target_parallel_for_simd_private_messages.cpp

#pragma omp target parallel for simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp target parallel for simd private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/target_private_messages.cpp

 #pragma omp target private(i)
   {}
   static int si;
 #pragma omp target private(si) // OK
   {}
 #pragma omp target map(i) private(i) // expected-error {{private variable cannot be in a map clause in '#pragma omp target' directive}}
   {}
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/target_simd_private_messages.cpp

#pragma omp target simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int m;
 #pragma omp target simd private(m)
   for (int k = 0; k < argc; ++k)
     m = k + 2;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/taskloop_private_messages.cpp

#pragma omp taskloop private(i, z)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp taskloop private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/OpenMP/taskloop_simd_private_messages.cpp

#pragma omp taskloop simd private(i)
   for (int k = 0; k < argc; ++k)
     ++k;
   static int si;
 #pragma omp taskloop simd private(si) // OK
   for(int k = 0; k < argc; ++k)
     si = k + 1;
 
   s6 = s6_0; // expected-note {{in instantiation of member function 'S6<float>::operator=' requested here}}
-  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float> >::operator=' requested here}}
+  s7 = s7_0; // expected-note {{in instantiation of member function 'S7<S6<float>>::operator=' requested here}}
   return foomain(argc, argv); // expected-note {{in instantiation of function template specialization 'foomain<int, char>' requested here}}
 }
 

clang/test/SemaTemplate/instantiate-member-expr.cpp

 
 class ExprEngine {
 public:
  typedef vector<S<void *> >CheckersOrdered;
  CheckersOrdered Checkers;
 
  template <typename CHECKER>
  void registerCheck(CHECKER *check) {
-   Checkers.push_back(S<void *>()); // expected-note {{in instantiation of member function 'vector<S<void *> >::push_back' requested here}}
+   Checkers.push_back(S<void *>()); // expected-note {{in instantiation of member function 'vector<S<void *>>::push_back' requested here}}
  }
 };
 
 class RetainReleaseChecker { };
 
 void f(ExprEngine& Eng) {
    Eng.registerCheck(new RetainReleaseChecker); // expected-note {{in instantiation of function template specialization 'ExprEngine::registerCheck<RetainReleaseChecker>' requested here}}
 }

clang/unittests/AST/DeclPrinterTest.cpp

 }
 
 TEST(DeclPrinter, TestTemplateArgumentList4) {
   ASSERT_TRUE(PrintedDeclCXX11Matches(
     "template<typename T> struct Z {};"
     "template<typename T> struct X {};"
     "Z<X<int>> A;",
     "A",
-    "Z<X<int> > A"));
-    // Should be: with semicolon, without extra space in "> >"
+    "Z<X<int>> A"));
+    // Should be: with semicolon
 }
 
 TEST(DeclPrinter, TestTemplateArgumentList5) {
   ASSERT_TRUE(PrintedDeclCXX98Matches(
     "template<typename T> struct Z {};"
     "template<typename T> struct X { Z<T> A; };",
     "A",
     "Z<T> A"));