jyknight added a comment. Hi, it seems that this change is incompatible with the `[NSItemProvider loadItemForTypeIdentifier:options:completionHandler:]` method's expected (but extremely weird and unusual!) usage.
Per https://developer.apple.com/documentation/foundation/nsitemprovider/1403900-loaditemfortypeidentifier?language=objc it takes an argument of type `NSItemProviderCompletionHandler` aka `void (^)(id<NSSecureCoding> item, NSError *error);`. However, `loadItemForTypeIdentifier:options:completionHandler` expects users to provide blocks of other types, e.g. `^(NSURL *url, NSError *error) { ... }` and introspects at runtime the resulting block object to determine the declared signature, and then provides the expected type. This is, of course, an extremely weird API (who'd ever expect a function to do runtime introspection of the callback's function signature and change the types passed to the function accordingly?). But, the expected usage previously type-checked, because of the bug fixed in this change (`NSURL*` is a subtype of `id<NSSecureCoding>`, so it was accepted before), and now throws an error. Should this change be reverted? Or have an exemption added for that one weird API? Or maybe that API needs to be modified to say it takes an argument of type "id" instead of NSItemProviderCompletionHandler? Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66831/new/ https://reviews.llvm.org/D66831 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
