rjmccall added a comment. In D58514#1435431 <https://reviews.llvm.org/D58514#1435431>, @wuhao5 wrote:
> In D58514#1435296 <https://reviews.llvm.org/D58514#1435296>, @rjmccall wrote: > > > In D58514#1435228 <https://reviews.llvm.org/D58514#1435228>, @wuhao5 wrote: > > > > > > Okay, so really just a block self-reference. We could really just add > > > > a feature for that that would avoid both the complexity and the expense > > > > of the self-capture dance. > > > > > > Is there a plan to cover this case? or is it a legitimate use case that > > > Clang should handle? > > > > > > You are currently relying on something that ARC doesn't guarantee, so the > > client code should be fixed to explicitly copy the block. I think we would > > be happy to consider a proposal in the long run to allow blocks to > > self-reference more easily, which will effectively bypass the problem. > > > I am not sure if I follow here - is it not that the weak pointer holds a > block that's in the stack but is supposed to be in the heap? In your code, ARC does not guarantee that the block pointer you're assigning to the weak reference will point to a heap copy of the block. ARC could force a copy of the block as part of the assignment, but it would be pointless because that copy would be immediately destroyed, leaving the weak reference holding `nil`, which is not what you want dynamically in your code. You need to force the block to be copied first. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58514/new/ https://reviews.llvm.org/D58514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
