This is NFC because only literal protocols are tracked at the moment.
Forward propagate (subtype -> supertype) only literal conformance
requirements since that helps solver to infer more types at
parameter positions.
```swift
func foo<T: ExpressibleByStringLiteral>(_: String, _: T) -> T {
fatalError()
}
func bar(_: Any?) {}
func test() {
bar(foo("", ""))
}
```
If one of the literal arguments doesn't propagate its
`ExpressibleByStringLiteral` conformance, we'd end up picking
`T` with only one type `Any?` which is incorrect.
This is not going to be necessary once bindings are filtered based
of requirements placed on a type variable.
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'.
SemanticARCOpts keeps on growing with various optimizations attached to a single
"optimization" manager. Move it to its own folder in prepation for splitting it
into multiple different optimizations and utility files.
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.
Functions that do not have a return, and instead end with 'unreachable'
due to NoReturnFolding will not have a ReturnNode in the connection
graph.
A caller calling a no return function then may not have a CGNode
corresponding to the call's result.
Fix the ConnectionGraph's verifier so we don't assert in such cases.
This ensures that when the dependency scanner is invoked with additional clang (`-Xcc`) options, the Clang scanner is correctly configured using these options.
Try to impose a simple structure that splits performing actions from the
pre and post-pipeline conditions. Wherever actions would take more than
a simple return, split them into functions. Refine functions that
perform effects to return status codes when they fail. Finally,
delineate functions that need semantic analysis from those that do not.
Overall this should be NFC.
At all call-sites, the extInfo passed as the third argument is computed directly
from the second argument, so we compute it directly in getBridgedFunctionType.
This assert doesn't consider reference storage types in its predicate.
Look through them since they're not relevant to the type consistency
check it's trying to pick out.
