The Clang importer was filtering out cases where the same declaration
is imported twice under the same name, which can now happen when one
is synchronous and one is asynchronous. This happens when, e.g., an
Objective-C class provides both a completion-hander-based asynchronous
version and a synchronous version, and the Swift names line up after
the completion-handler parameter is dropped.
Stop filtering these out. Overload resolution is capable of handling
synchronous/asynchronous overloading based on context.
Implement a basic set of isolation rules for actors, which includes:
* Asynchronous actor methods can be invoked on any actor instance.
* All mutable instance properties and synchronous instance methods are
only accessible via "self" or "super" within the context of the actor.
* Closures defined within an actor method are considered to be a
context distinct from the actor itself, are therefore are subject to
the same restrictions as above.
Together with a scheduler that ensures that asynchronous invocations
for a particular actor are serialized (at least up until they hit a
suspension point or return), this serves to isolate the actor's
instance state in a shallow manner: references to shared mutable state
can still be passed among actors, code can access global variables,
and one can still form and pass around unsafe pointers.
Pair this with some basic checking within actor contexts that
identifies a few obvious potential kinds of race conditions:
* References to captured mutable local variables from within closures.
* References to mutable global and static/class variables.
The latter are warnings, for which we currently don't have a great
suppression mechanism. That, and a lot of tuning, are still to come.
Fix the parsing of await/try/try?/try! so that the two can be nested
(e.g., `await try f()` or `try await f()`).
Then, fix the effects checking logic to preserve all throws-related
information under an `await`, and preserve all async/await-related
information under `try`/`try?`/`try!`.
Add a number of tests, and fix 'await' handling for string
interpolations as well.
Extend the check for completion handler parameters to also consider the
name of the parameter (not its argument label). If it's `completion` or
`completionHandler`, we have a completion handler. This extends our
API coverage for importing Objective-C methods with completion
handlers as 'async'.
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.
