[clang] [clang-tools-extra] [lldb] [clang] implement CWG1980 and CWG2064: instantiation-dependency improvements (PR #190495)

[Oliver Hunt via cfe-commits]

================
@@ -7399,17 +7480,50 @@ TemplateName ASTContext::getCanonicalTemplateName(TemplateName Name,
       // Keep popping from the back any deault arguments which are the same.
       if (I == int(CanonArgs.size() - 1))
         CanonArgs.pop_back();
-      NonCanonical = true;
+      AnyChanged = true;
+    }
+    return AnyChanged ? getDeducedTemplateName(
+                            CanonUnderlying,
+                            /*DefaultArgs=*/{DefArgs.StartPos, CanonArgs})
+                      : Name;
+  }
+  case TemplateName::QualifiedTemplate: {
+    auto *S = Name.getAsQualifiedTemplateName();
+    TemplateName Underlying = S->getUnderlyingTemplate();
+    if (CanonKind == CanonicalizationKind::Structural) {
+      return getCanonicalTemplateName(S->getUnderlyingTemplate(), IgnoreDeduced,
+                                      CanonKind, AnyNonCanonical);
+    }
+    // The qualifier needs to be attached to whatever entity it belongs to.
+    // Don't simply canonicalize the Underlying template, as that can turn a
+    // UsingShadowDecl into it's target, forming a nonsensical qualified name.
+    switch (Underlying.getKind()) {
+    case TemplateName::Template:
+      Underlying = TemplateName(cast<TemplateDecl>(
+          Underlying.getAsTemplateDecl()->getCanonicalDecl()));
+      break;
+    case TemplateName::UsingTemplate:
+      Underlying = TemplateName(cast<UsingShadowDecl>(
+          Underlying.getAsUsingShadowDecl()->getCanonicalDecl()));
+      break;
+    default:
+      llvm_unreachable(
+          "unexpected underlying template name kind for qualified template");
     }
----------------
ojhunt wrote:

is it worth making this a function on TemplateName? getUnderlyingCanonicalDecl (or getCanonicalUnderlyingDecl)?

It seems like something that _could_ be a general useful operation - though obviously some code is too eager about dropping sugared types, etc - and the subtlety around things like using decls seems sufficient to warrant a central function.

Though obviously that would depend on this being something we _do_ think people might reasonably want to do in other contexts 

https://github.com/llvm/llvm-project/pull/190495