Address a FIXME where lowered types rather than formal types were used
when converting from objc to native types which resulted in a failure to
convert block types.
Remove the default argument for the `memberType`
parameter and enforce that GenericFunctionType is
not passed. Also add a defaulted overload for the
property case, as they should never have a
GenericFunctionType interface type.
Only the root archetype is a OpaqueTypeArchetypeType; the nested types are
NestedArchetypeType. Use the correct predicate here.
Also remove a dead check in tuple lowering; the isa<OpaqueTypeArchetypeType>()
check is dominated by isTypeParameterOrOpaqueArchetype() which is always
true if isa<OpaqueTypeArchetypeType>() is true anyway.
Fixes rdar://problem/79597666.
AbstractionPattern::matchesTuple() is used by various assertions, and
the condition was too strict. Relax the condition to fix an assertion
failure in the case where an opaque result type has a tuple as its
underlying type.
Fixes https://bugs.swift.org/browse/SR-14426 / rdar://problem/76057095.
This change adds support for calling `operator()` from Swift code.
As the C++ interop manifesto describes, `operator()` is imported into Swift as `callAsFunction`.
Import APIs with the `swift_async_error` attribute in `zero_argument` or `nonzero_argument`
modes by checking the corresponding boolean argument to indicate the error status, instead of
treating it as part of the result tuple. rdar://70594666
Plumb generic signatures through the codegen for invoking foreign APIs as async, so that we
correctly handle APIs declared on ObjC lightweight generic classes. rdar://74361267
An ObjC API maybe imported as async that had multiple non-error arguments to
its completion handler, which we treat in Swift as returning a tuple. Use a new
form of abstraction pattern to represent this return type, to maintain the
correct relation between individual tuple elements and the Clang block parameter
types they map to.
When lowering the type for `@objc` entry points of async declarations, restore
the original ObjC signature with the completion handler argument in the lowered
SIL type.
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).
Printing an AbstractionPattern with a CXXMethodType would previously
fail because the code would try to get a Clang type instead. I could
add an if statement but instead, I split off the cases related to C++
method type into a new block, as that seems to follow the pattern in
AbstractionPattern::print().
- Getting a tuple element from an opaque return type `AbstractionPattern` should produce another
opaque abstraction pattern.
- Relax an assertion failure when lowering metatypes against opaque return type abstraction
patterns.
Fixes rdar://problem/58787252.
MSVC does not realize that the switch is exhaustive and requires that
the path is explicitly marked as unreachable. This silences the C4715
warning ("not all control paths return a value").
Specifically, I split it into 3 initial categories: IR, Utils, Verifier. I just
did this quickly, we can always split it more later if we want.
I followed the model that we use in SILOptimizer: ./lib/SIL/CMakeLists.txt vends
a macro (sil_register_sources) to the sub-folders that register the sources of
the subdirectory with a global state variable that ./lib/SIL/CMakeLists.txt
defines. Then after including those subdirs, the parent cmake declares the SIL
library. So the output is the same, but we have the flexibility of having
subdirectories to categorize source files.