Anastasia added a comment. In https://reviews.llvm.org/D43783#1272001, @AlexeySotkin wrote:
> 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. > > > The spec is not clear about what is "statically determinable". To me, in the > example provided we can not resolve the `bl()` call without inlining `foo`, > even at IR level. As Sam noted, that leads to indirect call and require > support of functions pointers. > I see a contradiction in the spec in allowing blocks to be a function > argument and disallowing function pointers at the same time. I think maybe > the spec should be changed to clarify existing restrictions or add more > restrictions for cases when blocks are passed as function argument. I am not sure that blocks in function call parameters contradict the rule of them being statically determinable though. You can statically determine what blocks are being passed into a function. There might be multiple different ones though. However, it should be possible to lower the function pointers into the direct calls. 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
