rjmccall added a comment. In https://reviews.llvm.org/D32210#731192, @ahatanak wrote:
> 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? Yes, I think so. You'll need to document that, of course. John. https://reviews.llvm.org/D32210 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
