yaxunl added a comment. In https://reviews.llvm.org/D43783#1215573, @Anastasia wrote:
> In https://reviews.llvm.org/D43783#1212485, @yaxunl wrote: > > > In https://reviews.llvm.org/D43783#1204353, @svenvh wrote: > > > > > Sorry for digging up an old commit... > > > > > > Apparently this broke block arguments, e.g. the following test case: > > > > > > int foo(int (^ bl)(void)) { > > > return bl(); > > > } > > > > > > int get21() { > > > return foo(^{return 21;}); > > > } > > > > > > int get42() { > > > return foo(^{return 42;}); > > > } > > > > > > > > > In particular, the VarDecl that `getBlockExpr()` sees doesn't have an > > > initializer when the called block comes from an argument (causing clang > > > to crash). > > > > > > Sorry for the delay. I think block should not be allowed as function > > argument since this generally leads indirect function calls therefore > > requires support of function pointer. It will rely on optimizations to get > > rid of indirect function calls. > > > The idea was to allow blocks as function parameters because they are > statically known at each function call. This can be resolved later at IR > level instead of frontend. I am also not sure there can be other corner cases > where it wouldn't work in Clang since we can't leverage analysis passes here. > I feel this might be a risky thing to do in Clang. Currently it doesn't work > for the examples provided and therefore breaking the compliance with the spec. I agree this patch should be reverted for conformance to spec. I will do that. Thanks. Repository: rC Clang https://reviews.llvm.org/D43783 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
