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.
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
Introduce a few new options to tweak the output of this script:
-show-overlay Show overlay API in addition to Objective-C module API
-show-doc-comments Show documentation comments
-show-unavailable Show declarations that are unavailable in Swift
As requested by rdar://problem/39384089.
Teach swift-api-dump to pass through a Swift version flag, so it's
easy to see the effects of Swift 3 compatibility mode vs. Swift 4.
While I'm here, drop the "-always-argument-labels" flag (which we
don't need now that we've settled the argument-label rules) and
replace 'OSX' with 'macOS'.
* Don't override the name of the builtin `str`
* Use raw strings for regex matches
* Replace a couple of unused variables by `_`
* Remove an unused argument from `create_dump_module_api_args` (the arg
is never used in the body of the function, and it's only called from
this file).
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
When performing Swift API dumps, it's helpful to avoid putting
redundant APIs into the results. Therefore, filter out any APIs that
are overrides of another API or are witnesses for a protocol
requirement, since the original definition (that doesn't override any
other or is a protocol requirement) is what determines the APIs name.
The default first argument label rules are confusing reviewers looking
at API dumps. Even though it's more verbose, always put in argument
labels explicitly.
We're going to delay NS prefix stripping for a bit. Change the API
dump script accordingly, and bump the Swift name lookup table format
version number so this doesn't break everyone who has already run
swift-api-dump.py.
- Since this file has a Python shebang (`#!/usr/bin/env python`) at the top, it can be invoked directly, without specifying which Python interpreter to use on the command line.
- Use the `%(prog)s` substitution instead of writing the program name again explicitly.
The omit-needless-words script has grown into a more general "API
dumping" script. Make it a bit more useful by installing it alongside
swift-ide-test, symlinking it in the build directory next to
swift-ide-test (for Swift developers), and defaulting to using the
swift-ide-test in the same directory as the script. Now it's fairly
easy to dump the API for a given SDK with, e.g.,
swift-api-dump.py -s iphoneos
