[PATCH] D155396: [Sema][ObjC] Propagating value-dependent errors into BlockExpr

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 19 06:54:44 PDT 2023


hokein added a comment.





================
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);
----------------
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.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155396/new/

https://reviews.llvm.org/D155396



More information about the cfe-commits mailing list