================ @@ -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