akhuang added inline comments.
================ Comment at: clang/lib/CodeGen/CGClass.cpp:3097 + FD->getLocation(), FD->getLocation()); + CGF.EmitFunctionBody(FD->getBody()); + CGF.FinishFunction(); ---------------- efriedma wrote: > Is there any way we can use GenerateCode as the entrypoint here, instead of > calling EmitFunctionBody directly? Without this patch, EmitFunctionBody has > exactly one caller, so this makes the control flow and special cases more > complicated to reason about. For example, there's some special coroutine > handling in GenerateCode. Changed to using GenerateCode -- had to add another case to the path in GenerateCode to make sure we emit different things for the call op body inside __impl and the call op body inside the call op function. ================ Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1472 + // the call operator body. + EmitLambdaStaticInvokeBody(cast<CXXMethodDecl>(FD)); } else if (FD->isDefaulted() && isa<CXXMethodDecl>(FD) && ---------------- efriedma wrote: > Does this pass the correct value of "this"? EmitLambdaStaticInvokeBody > creates a new alloca to represent "this", but it's already an argument to the > function. > > Granted, it only matters in really obscure cases, but still. That's true, the "this" won't be passed correctly. Actually, would it be fine to just emit the original call op body? (so that the same function body is emitted twice -- once in the call op and once in __impl). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137872/new/ https://reviews.llvm.org/D137872 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
