================
@@ -1332,6 +1332,54 @@ llvm::DIType *CGDebugInfo::CreateType(const
TemplateSpecializationType *Ty,
auto PP = getPrintingPolicy();
Ty->getTemplateName().print(OS, PP, TemplateName::Qualified::None);
+ SourceLocation Loc = AliasDecl->getLocation();
+
+ if (CGM.getCodeGenOpts().DebugTemplateAlias) {
+ // TemplateSpecializationType doesn't know if its template args are
+ // being substituted into a parameter pack. We can find out if that's
+ // the case now by inspecting the TypeAliasTemplateDecl template
+ // parameters. Insert Ty's template args into SpecArgs, bundling args
+ // passed to a parameter pack into a TemplateArgument::Pack.
+ SmallVector<TemplateArgument> SpecArgs;
+ {
+ ArrayRef SubstArgs = Ty->template_arguments();
+ for (const NamedDecl *P : TD->getTemplateParameters()->asArray()) {
+ if (P->isParameterPack()) {
+ SpecArgs.push_back(TemplateArgument(SubstArgs));
+ break;
+ }
+ // Skip defaulted args.
+ if (SubstArgs.empty()) {
+ // If SubstArgs is now empty (we're taking from it each iteration)
and
+ // this template parameter isn't a pack, then that should mean we're
+ // using default values for the remaining template parameters.
+ break;
----------------
OCHyams wrote:
> The three kinds you check for should be sufficient afaik. Places around clang
> consistently only deal with these three types of parameter decls.
Excellent, that is reassuring, thanks.
I'm wondering if you've got any ideas about my dependent value situation:
```
template <int I1 = 5, int I2 = I1>
using B = int;
B<> b;
```
The current default-argument-gathering tactic can't cope with dependent default
expressions/types. Do you know if there's any way that I can "resolve", for
lack of a better word, the template parameter default expression to get an
expression `= 5` rather than the dependent `= I1`? Presumably this is doable,
because we've got a specialisation that defines what `I1` is (are there cases
where this could never work... maybe with SFINAE? I'm not sure).
I'm continuing to look into it, I'm only asking in case you know off the top of
your head, no problem if not.
https://github.com/llvm/llvm-project/pull/87623
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
