ahatanak added a comment. In https://reviews.llvm.org/D32210#730777, @rjmccall wrote:
> The rule we actually want is that no reference to the block derived from the > parameter value will survive after the function returns. You can include > examples of things that would cause potential escapes, but trying to actually > lock down the list seems ill-advised. > > Are you sure you want to try to enforce this in the frontend? In Swift, we > discovered that we needed some way of escaping the static checking in order > to make this practical, because there are a lot of patterns that locally look > like escapes but really aren't (e.g. passing the block to dispatch_async and > then waiting for that to complete). Seems more like a static analysis than a > frontend warning. I'm actually not so sure we want to enforce this in the front-end. I was following what I thought Swift was doing, which is to reject code that can potentially cause noescape closures to escape. But that might be too restrictive and can reject legitimate code in some cases as Adam pointed out. I agree that static analysis would probably be better at detecting usages of noescape blocks that are likely to cause them to escape. Do you think we should remove all the restrictions I listed and instead count on the users to ensure noescape blocks do not escape? https://reviews.llvm.org/D32210 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
