================
@@ -382,11 +381,25 @@ CIRGenFunction::emitCoroutineBody(const CoroutineBodyStmt
&s) {
// Handle allocation failure if 'ReturnStmtOnAllocFailure' was provided.
if (s.getReturnStmtOnAllocFailure())
cgm.errorNYI("handle coroutine return alloc failure");
-
+ cir::CoroRetPointOp coroRet = nullptr;
+ mlir::OpBuilder::InsertPoint coroRetRegion;
{
assert(!cir::MissingFeatures::generateDebugInfo());
ParamReferenceReplacerRAII paramReplacer(localDeclMap);
RunCleanupsScope resumeScope(*this);
+ mlir::OpBuilder::InsertPoint coroRetBody;
+ coroRet = cir::CoroRetPointOp::create(
+ builder, openCurlyLoc,
+ /*bodyBuilder=*/
+ [&](mlir::OpBuilder &b, mlir::Location) {
+ coroRetBody = b.saveInsertionPoint();
----------------
erichkeane wrote:
I'm not a huge fan of doing stuff like this, we've seen this strategy get
fragile in the past. Is it problematic to extract the regions of code that od
this into a function we can call here instead?
https://github.com/llvm/llvm-project/pull/213191
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
