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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
