When a given Objective-C method has a completion handler parameter
with an appropriate signature, import that Objective-C method as
async. For example, consider the following CloudKit API:
- (void)fetchShareParticipantWithUserRecordID:(CKRecordID
*)userRecordID
completionHandler:(void (^)(CKShareParticipant * _Nullable shareParticipant, NSError * _Nullable error))completionHandler;
With the experimental concurrency model, this would import as:
func fetchShareParticipant(withUserRecordID userRecordID: CKRecord.ID) async throws -> CKShare.Participant?
The compiler will be responsible for turning the caller's continuation
into a block to pass along to the completion handler. When the error
parameter of the completion handler is non-null, the async call
will result in that error being thrown. Otherwise, the other arguments
passed to that completion handler will be returned as the result of
the async call.
async versions of methods are imported alongside their
completion-handler versions, to maintain source compatibility with
existing code that provides a completion handler.
Note that this only covers the Clang importer portion of this task.
When a Swift declaration witnesses an ObjC protocol requirement, its error convention needs to
match the requirement. Furthermore, if there are different protocol requirements that the
Swift method can witness, with different error conventions, we need to bail out because we
can't simultaneously match all of them. Fixes rdar://problem/59496036 | SR-12201.
Expose a ForeignErrorConvention::Info struct, so that the
ClangImporter can also utilize this space-efficient
storage. Eliminates the ClangImporter's ad-hoc representation, and
shaves off a pointer or so off of the ImportedName size.
While we're out it, make some of the bools bitfields to shave off
another pointer in size. Total ImportedName size is now 6.
Add a new convention to describe what happens with
nonzero_result on a type that isn't imported as Bool.
This isn't really a safe convention to implement, but
calls are fine.
Implements <rdar://21715350>.
Swift SVN r29953
For some reason this was only breaking with initializers, and not
ordinary methods, where there was both a throwing and non-throwing
version of the same method.
Fixes <rdar://problem/20922973>.
Swift SVN r28534
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
