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.
We can synthesize the default init() and the implicit deinit in a class in
any order, depending on the order of primary files and how that class was
used in other primary files.
Make sure that EmittedMembersRequest puts the destructor at the end with
all other synthesized members, so that we produce the same object file in
any case.
'-dump-parse' for the following code used to hit an assertion failure:
struct MyStruct {}
_ = { (val: MyStruct) in }
Because 'isNonEphemeral()' on 'val' parameter unintentionally causes
'InterfaceTypeRequest::evaluate()'. Since 'isNonEphemeral()' inference
based on the interface type is not possible after type checking, return
'false' unless 'hasInterfaceType()'
Also:
* Dump parameter list on 'EnumElementDecl' as well
* Adjust the position of 'range=...' in parameter list dumping
When a nominal type and its extensions coexist in the same module, mangling may
use the nominal type as the context for extension members. We should preserve this
mechanism for types marked as @_originallyDefinedIn to maintain ABI stability.
rdar://64538537
Now that the previous commits have removed the data dependencies on TypeLoc, remove the TypeLoc and replace it with a TypeRepr. This makes RequirementRepr a purely syntactic object once again.
```
class Generic<T> {
@objc dynamic func method() {}
}
extension Generic {
@_dynamicReplacement(for:method())
func replacement() {}
}
```
The standard mechanism of using Objective-C categories for dynamically
replacing @objc methods in generic classes does not work.
Instead we mark the native entry point as replaceable.
Because this affects all @objc methods in generic classes (whether there
is a replacement or not) by making the native entry point
`[dynamically_replaceable]` (regardless of optimization mode) we guard this by
the -enable-implicit-dynamic flag because we are late in the release cycle.
* Replace isNativeDynamic and isObjcDynamic by calls to shouldUse*Dispatch and
shouldUse*Replacement
This disambiguates between which dispatch method we should use at call
sites and how these methods should implement dynamic function
replacement.
* Don't emit the method entry for @_dynamicReplacement(for:) of generic class
methods
There is not way to call this entry point since we can't generate an
objective-c category for generic classes.
rdar://63679357
The fact that a declaration has `@_show_in_interface` shouldn't be
used to decide whether something has underscored naming, which
is just one specific kind of check regarding naming only.
Move the check for this attribute out one level.
rdar://63120829
