zyn0217 wrote: So the problem is that we would have another implicitly-created explicit template specialization `foo<int, int>` in the process of the DeduceTemplateArguments, and that specialization would share the same `FunctionTemplateSpecializationInfo` with the eventual template specialization that ends up being `D` in the `getRawCommentForAnyRedecl`, while the implicitly-created specialization would
1) have the explicit specialization flag set in `CheckFunctionTemplateSpecialization` 2) become the previous declaration of the last explicit specialization 3) have no `ExtInfo` set so one cannot get any template parameters from it. So the status-quo is seemingly violating the contracts of `NumTemplParamLists` / `TemplParamLists` in light of their intents. The `TemplateParameterList` would be attached to the newly created explicit specialization prior to the call to `CheckFunctionTemplateSpecialization()`, so one solution (which essentially preserves the ExtInfo in the implicitly-created specialization) is to add the following to `CheckFunctionTemplateSpecialization(),` in the code block below the comment. ```cpp // Mark the prior declaration as an explicit specialization, so that later // clients know that this is an explicit specialization. ``` ```cpp SmallVector<TemplateParameterList *, 4> TPL; for (unsigned I = 0; I < FD->getNumTemplateParameterLists(); ++I) TPL.push_back(FD->getTemplateParameterList(I)); Specialization->setTemplateParameterListsInfo(Context, TPL); ``` An alternative might be to teach `DeclInfo::fill()` not to rely on `getNumTemplateParameterLists()`, but that way we still lack the `TemplateParameterList`. https://github.com/llvm/llvm-project/pull/108475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
