When a completion-handler parameter has text before, e.g.,
"WithCompletionHandler", put the extra text on the base name rather
than the corresponding parameter. This ensures that we don't lose the
detail from the text, but always put it into a consistent place.
Extend the set of completion-handler names we look for to infer an
`async` import of an Objective-C method, which includes:
* (with)CompletionBlock
* (with)reply
* (with)replyTo
both as parameter names and as base name suffixes.
The new `swift_async_name` attribute allows Clang declarations to specify
their Swift names only for `async` import, which may differ from those used
for importing as a completion handler.
Implements rdar://70111787.
Allow SILGen to not crash when invoking foreign async methods by emitting
`undef` for the completion callback going into the call, and for the
results that would be channeled back through awaiting the continuation.
It's possible to have a "UnresolvedUsingValueDecl" with a "CXXConstructorName". If that's the case (or if there's any other unkown decl) bail instead of crashing.
When a completion handler parameter has a selector piece that ends with
"WithCompletion(Handler)", prepend the text before that suffix to the
base name or previous argument label, as appropriate. This ensures that
we don't lose information from the name, particularly with delegate names.
Sometimes, on windows, we get a function template wrapping the
constructor decl. In this case, look through the function template to
find the constructor decl.
* Check isAggregate instead of hasUserDeclaredConstructor.
* Rename addEmptyArgNamesForCxxFunc -> addEmptyArgNamesForClangFunction.
* Other minor fixes and cleanups.
Because C++ constructors always take a `this` pointer to the object to
be initialized, we mark the SIL function return type with the `@out`
attribute.
On the IRGen side, we retrofit support for formal indirect return values as
well as thin metatypes.
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.
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
We need ClangImporterOptions to be persistent for several scenarios: (1)
when creating a sub-ASTContext to build Swift modules from interfaces; and
(2) when creating a new Clang instance to invoke Clang dependencies scanner.
This change is NFC.
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.
This is a roll-forward of https://github.com/apple/swift/pull/32950, with explicit c++17 version removed from tests. This is not needed since C++17 is the default anyway.
--
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Resolves https://bugs.swift.org/browse/SR-12591.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
This adds support to `ClangImporter` to import C++ member function operators as static methods into Swift, which is part of SR-12748.
The left-hand-side operand, which gets passed as the `this` pointer to the C++ function is represented as an additional first parameter in the Swift method. It gets mapped back in SILGen.
Two of the tests are disabled on Windows because we can't yet call member functions correctly on Windows (SR-13129).
Re-order operator case statements and tests. The order now follows the order defined in `llvm-project/clang/include/clang/Basic/OperatorKinds.def`.
Also, adds operator character(s) in parentheses.
* [cxx-interop] Add support for C++ shift operators.
Support imported C++ `<<` and `>>` operators in Swift.
* Update test names of existing operators
... to match the new ones.
Co-authored-by: Michael Forster <forster@google.com>
We used to compute the init kind from the overridden declaration;
this was switched to use the base declaration in 42f72cb0d.
Refactor the init kind computation a little to get the old behavior
back. Otherwise, if a class defines an initializer named -init, we
always import it as designated by virtue of overridding NSObject's
-init.
Fixes <rdar://problem/56674158>.
The only thing this was used for is to test if the total number of
parameters was 1, in which case we did the same thing we did for a
first parameter except in one very contrived case: a method with more
than one parameter whose base name starts with "set" and whose first
parameter is an NSZone. There are zero of these in the macOS or iOS
SDKs, and probably even fewer in third-party code.
Previously we only did this for factory methods, but there's no reason
why we can't do it for regular init methods too, and doing so
simplifies the signature of SwiftDeclConverter::importConstructor.
Also remove some indirection through helper functions in ClangAdapter.
These were more useful back when Swift looked directly at API notes
instead of relying on Clang turning them into attributes; now they're
just an extra hop for no reason.
`tok.getLiteralData()` does not work for a macro imported from a clang module (returns `nullptr`), while `getSpellingOfSingleCharacterNumericConstant` covers both kinds of macros (defined in source or imported from a module).
Unfortunately this currently only matters for an internal tool so I cannot accompany this change with a test case.
