Skip to content

Conversation

@tbaederr
Copy link
Contributor

So the static invoker's Function still points to the static invoker instead of the call operator of the lambda record. This is important for a later commit.

So the static invoker's Function still points to the static invoker instead of the call operator of the lambda record. This is important for a later commit.
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" clang:bytecode Issues for the clang bytecode constexpr interpreter labels Sep 19, 2025
@llvmbot
Copy link
Member

llvmbot commented Sep 19, 2025

@llvm/pr-subscribers-clang

Author: Timm Baeder (tbaederr)

Changes

So the static invoker's Function still points to the static invoker instead of the call operator of the lambda record. This is important for a later commit.


Full diff: https://github.com/llvm/llvm-project/pull/159733.diff

2 Files Affected:

  • (modified) clang/lib/AST/ByteCode/Compiler.cpp (+18-1)
  • (modified) clang/lib/AST/ByteCode/Context.cpp (-17)
diff --git a/clang/lib/AST/ByteCode/Compiler.cpp b/clang/lib/AST/ByteCode/Compiler.cpp index 1340a84a7d44d..fafec47f7de3c 100644 --- a/clang/lib/AST/ByteCode/Compiler.cpp +++ b/clang/lib/AST/ByteCode/Compiler.cpp @@ -6077,7 +6077,24 @@ bool Compiler<Emitter>::emitLambdaStaticInvokerBody(const CXXMethodDecl *MD) { assert(cast<CompoundStmt>(MD->getBody())->body_empty()); const CXXRecordDecl *ClosureClass = MD->getParent(); - const CXXMethodDecl *LambdaCallOp = ClosureClass->getLambdaCallOperator(); + const FunctionDecl *LambdaCallOp; + assert(ClosureClass->captures().empty()); + if (ClosureClass->isGenericLambda()) { + LambdaCallOp = ClosureClass->getLambdaCallOperator(); + assert(MD->isFunctionTemplateSpecialization() && + "A generic lambda's static-invoker function must be a " + "template specialization"); + const TemplateArgumentList *TAL = MD->getTemplateSpecializationArgs(); + FunctionTemplateDecl *CallOpTemplate = + LambdaCallOp->getDescribedFunctionTemplate(); + void *InsertPos = nullptr; + const FunctionDecl *CorrespondingCallOpSpecialization = + CallOpTemplate->findSpecialization(TAL->asArray(), InsertPos); + assert(CorrespondingCallOpSpecialization); + LambdaCallOp = CorrespondingCallOpSpecialization; + } else { + LambdaCallOp = ClosureClass->getLambdaCallOperator(); + } assert(ClosureClass->captures().empty()); const Function *Func = this->getFunction(LambdaCallOp); if (!Func) diff --git a/clang/lib/AST/ByteCode/Context.cpp b/clang/lib/AST/ByteCode/Context.cpp index 6e6c60925a70f..22ae64ede2f1c 100644 --- a/clang/lib/AST/ByteCode/Context.cpp +++ b/clang/lib/AST/ByteCode/Context.cpp @@ -465,23 +465,6 @@ const Function *Context::getOrCreateFunction(const FunctionDecl *FuncDecl) { // be a non-static member function, this (usually) requiring an // instance pointer. We suppress that later in this function. IsLambdaStaticInvoker = true; - - const CXXRecordDecl *ClosureClass = MD->getParent(); - assert(ClosureClass->captures().empty()); - if (ClosureClass->isGenericLambda()) { - const CXXMethodDecl *LambdaCallOp = ClosureClass->getLambdaCallOperator(); - assert(MD->isFunctionTemplateSpecialization() && - "A generic lambda's static-invoker function must be a " - "template specialization"); - const TemplateArgumentList *TAL = MD->getTemplateSpecializationArgs(); - FunctionTemplateDecl *CallOpTemplate = - LambdaCallOp->getDescribedFunctionTemplate(); - void *InsertPos = nullptr; - const FunctionDecl *CorrespondingCallOpSpecialization = - CallOpTemplate->findSpecialization(TAL->asArray(), InsertPos); - assert(CorrespondingCallOpSpecialization); - FuncDecl = CorrespondingCallOpSpecialization; - } } // Set up argument indices. unsigned ParamOffset = 0; 
@tbaederr tbaederr merged commit 03e16c8 into llvm:main Sep 19, 2025
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang:bytecode Issues for the clang bytecode constexpr interpreter clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category

2 participants