================
@@ -6484,6 +6499,57 @@ class SubstTemplateTypeParmType final
   }
 };
 
+/// Represents the result of substituting a set of types as a template argument
+/// that needs to be expanded later.
+///
+/// These types are always dependent and produced depending on the situations:
+/// - SubstTemplateTypeParmPack represents a pack expansion that had to be
+/// delayed,
+/// - TODO: represents a pack expansion represented by a builtin.
+class SubstPackType : public Type, public llvm::FoldingSetNode {
+  friend class ASTContext;
+
+  /// A pointer to the set of template arguments that this
+  /// parameter pack is instantiated with.
+  const TemplateArgument *Arguments;
+
+protected:
+  SubstPackType(TypeClass Derived, QualType Canon,
+                const TemplateArgument &ArgPack);
+
+public:
+  unsigned getNumArgs() const { return SubstPackTypeBits.NumArgs; }
+
+  TemplateArgument getArgumentPack() const;
+
+  void Profile(llvm::FoldingSetNodeID &ID);
+  static void Profile(llvm::FoldingSetNodeID &ID,
+                      const TemplateArgument &ArgPack);
+
+  static bool classof(const Type *T) {
+    return T->getTypeClass() == SubstTemplateTypeParmPack ||
+           T->getTypeClass() == SubstBuiltinTemplatePack;
+  }
+};
+
+/// Represents the result of substituting a builtin template as a pack.
+class SubstBuiltinTemplatePackType : public SubstPackType {
+  friend class ASTContext;
+
+  SubstBuiltinTemplatePackType(QualType Canon, const TemplateArgument 
&ArgPack);
----------------
mizvekov wrote:

I haven't taken the time to review this in-depth yet, sorry but I have been 
busy with other things.

Taking a step back a little bit, I am a bit surprised the changes for 
implementing these builtins became so involved, with new AST nodes and changes 
to TreeTransform and all of that.

I would have expected the existing builtin template infrastructure to handle 
this quite well, and the implementation would only need to touch around 
`checkBuiltinTemplateIdType` in `SemaTemplate.cpp`.

So what happened, is this trying to go for more performance than what that 
simpler implementation would have provided?

If that's the case, can we try the simpler implementation first, and then go 
more complicated if needed, with numbers to back it up?

https://github.com/llvm/llvm-project/pull/106730
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to