Literal closures are only ever directly referenced in the context of the expression they're written in,
so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if
they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context
before emitting the closure, and then lowering its main entry point's calling convention at that
level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns
to the correct representation for a different abstraction level.
Literal closures are only ever directly referenced in the context of the expression they're written in,
so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if
they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context
before emitting the closure, and then lowering its main entry point's calling convention at that
level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns
to the correct representation for a different abstraction level.
When converting an ObjC method type which is being called as async to a
Swift function type, some of the values passed to the ObjC method's
completion handler are converted to return values of the Swift function.
The flag and error parameters, however, if present, are ignored.
When abstracting the result type for the Swift method, the formal type
of the corresponding parameter in the ObjC method's completion handler
is used. Digging out that parameter entails indexing into the
parameters of the completion handler. Previously, the indexing logic
relied on the error appearing before the flag if both appeared before
the value of interest. Here, the indexing is tweaked to check both
special indices for each possible index until the first that matches
neither is found.
rdar://81625544
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.
