[clang] [clang] Implement P2582R1: CTAD from inherited constructors (PR #98788)

[Haojian Wu via cfe-commits]

================
@@ -1216,10 +1308,225 @@ void DeclareImplicitDeductionGuidesForTypeAlias(
             ->getDeductionCandidateKind() == DeductionCandidate::Aggregate)
       continue;
 
-    BuildDeductionGuideForTypeAlias(SemaRef, AliasTemplate, F, Loc);
+    BuildDeductionGuideForTypeAlias(SemaRef, AliasTemplate, F, Loc,
+                                    DeducingTemplate, DerivedClassMapperType);
   }
 }
 
+void DeclareImplicitDeductionGuidesFromInheritedConstructors(
+    Sema &SemaRef, TemplateDecl *Template, ClassTemplateDecl *Pattern,
+    TypeSourceInfo *BaseTSI, unsigned BaseIdx) {
+  auto &Context = SemaRef.Context;
+  DeclContext *DC = Template->getDeclContext();
+  const auto *BaseTST = BaseTSI->getType()->getAs<TemplateSpecializationType>();
+  if (!BaseTST)
+    return;
+  SourceLocation BaseLoc = BaseTSI->getTypeLoc().getBeginLoc();
+
+  TemplateDecl *BaseTD = BaseTST->getTemplateName().getAsTemplateDecl();
+  if (!BaseTD)
+    return;
+
+  // Subsitute any parameters with default arguments not present in the base,
+  // since partial specializations cannot have default parameters
----------------
hokein wrote:

Thanks a lot for the explanations and clarifications. 

> along with the transformed alias deduction guides. With these in place, that deduction will fail, because it is not possible to instantiate the partial specialization of CC<R> for the deduction guide return type R (which is Base<InBase> in practice).
> 
> The reason this substitution fails is because NotInBase cannot be determined from Base<InBase>. Since partial specializations cannot have default arguments, the fact that NotInBase is defaulted in the derived class is not respected.

This makes sense. And it seems like another issue in the standard, and we should report to the CWG as well.

One alternative is to omit this case until the CWG addresses it. If doing so significantly simplifies the implementation, I'd lean towards that approach. However, if the current solution is more practical without much added complexity, I’m fine with proceeding as is.


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