danix800 added inline comments.
================ Comment at: clang/lib/Sema/SemaExpr.cpp:16749-16753 + bool ContainsError = llvm::any_of(BSI->Returns, [](const ReturnStmt *Return) { + const auto *RetValExpr = Return->getRetValue(); + return RetValExpr && RetValExpr->containsErrors(); + }); + BlockExpr *Result = new (Context) BlockExpr(BD, BlockTy, ContainsError); ---------------- hokein wrote: > aaron.ballman wrote: > > Hmmm -- is the block *expression* what contains the errors in this case or > > is it the block declaration? I would have expected this to be an issue for > > the block declaration created for the block expression. CC @rjmccall > I think a reasonable model is to follow how we handle `FunctionDecl`, as > `BlockDecl` and `FunctionDecl` are similar function-decl concepts. > > For the crash case like `int (^a)() = ^() { return undefined; }`, we should: > > - invalidate the `BlockDecl` as its returned type can not be deduced because > of the error return stmt (similar to `FunctionDecl`, we invalidate it for > `auto func() { return undefined; }`) > - for an invalid `BlockDecl`, we should not build a `BlockExpr` that refers > to it (we don't build `DeclRefExpr` for invalid `FunctionDecl`). For error > recovery, we should use `RecoveryExpr`. > > So I think the reasonable fix is to invalidate the BlockDecl (calling > `Decl->setInvalidDecl()`) if its body has any error stmt, and return > `ExprError()` if the BlockDecl is invalid. > Thanks for sharing and pointing out the right direction. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155396/new/ https://reviews.llvm.org/D155396 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits