Allow an 'async' function to overload a non-'async' one, e.g.,
func performOperation(_: String) throws -> String { ... }
func performOperation(_: String) async throws -> String { ... }
Extend the scoring system in the type checker to penalize cases where
code in an asynchronous context (e.g., an `async` function or closure)
references an asychronous declaration or vice-versa, so that
asynchronous code prefers the 'async' functions and synchronous code
prefers the non-'async' functions. This allows the above overloading
to be a legitimate approach to introducing asynchronous functionality
to existing (blocking) APIs and letting code migrate over.
Allow the declaration of @objc async methods, mapping them to a
completion-handler API in Objective-C. This covers most of the
checking and semantics within the type checker:
* Declaring @objc async methods and checking their parameter/result types
* Determining the default Objective-C selector by adding
completionHandler/WithCompletionHandler as appropriate
* Determining the type of the completion handler parameter
* Inferring @objc from protocol requirements
* Inferring @objc from an overridden method
Refactor TypeCheckFunctionBodyRequest to return
the type-checked body, and remove
`typeCheckAbstractFunctionBody` in favor of
a method on AbstractFunctionDecl. In addition,
start returning an ErrorExpr body instead of
a partially type-checked body if type-checking
fails.
Generalize `ClassDecl::getEmittedMembers()` to operate on an
`IterableDeclContext`, so that it can be for other nominal types,
extensions, etc. Rename to `getSemanticMembers()` to indicate that
these are all of the members that are semantically part of that
context.
Clean up the implementation slightly so it only forces type checking
for the conformances within that particular context (using
`getLocalConformances()`) and doesn't need to list out each of the
protocols it cares about.
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.
LLVM, as of 77e0e9e17daf0865620abcd41f692ab0642367c4, now builds with
-Wsuggest-override. Let's clean up the swift sources rather than disable
the warning locally.
Fast completion replaces the body ('BraceStmt') of function decls with
other bodies parsed from different source buffers from the original
source buffer. That means the source range of the body and the location
of the function declaration itself might be in different buffers.
Previously, FuncDecl::getSourceRange() used to use the 'func' keyword decl
as the start loc and 'getBodySourceRange().End' as the end loc. This
breaks a SourceRange invariant where the start and end loc must be
in the same buffer.
This patch add a new function 'getOriginalBodySourceRange()' which
always return the source range of the original body of the function. And
use that from 'getSourceRange()' functions.
The orignal body source range is stored in a side table in ASTContext so
that normal compilation doesn't consume space for that extra info.
`IsCxxNonTrivial` is set for a variety or reasons, for example, it's set
when the struct contains bitfields, has a custom destructor, or a custom
copy constructor. The name `IsCxxNotTriviallyCopyable` only implies the
latter.
Since the two ExtInfos share a common ClangTypeInfo, and C++ doesn't let us
forward declare nested classes, we need to hoist out AnyFunctionType::ExtInfo
and SILFunctionType::ExtInfo to the top-level.
We also add some convenience APIs on (AST|SIL)ExtInfo for frequently used
withXYZ methods. Note that all non-default construction still goes through the
builder's build() method.
We do not add any checks for invariants here; those will be added later.
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
Add a new GenericContext::getParsedGenericParams(). This produces
the same value as GenericContext::getGenericParams() if the generic
parameter list was written in source. For extensions and protocols,
this returns nullptr without synthesizing anything.
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
Framework authors may move a type along with its extensions from
a high-level framework to a low-level one. We should compare
alternative module names for them to check if they should be considered from
the same module to preserve ABI stability.
rdar://65889766
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
