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
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).
Because violations of this might have made an AbstractionPattern incorrectly show up as abstract, it's possible that this will cause an ABI change. However, I haven't been able to find any examples where it does, and certainly there's no way we can promise to maintain the old behavior, especially since it's not done consistently.
Lowering a SIL type should be a pure function of the formal type of a value and the
abstraction pattern it's being lowered against, but we historically did not carry
enough information in abstraction patterns to lower generic parameter types, so we
relied on a generic context signature that would be pushed and popped before lowering
interface types. This patch largely eliminates the necessity for that, by making it
so that `TypeClassifierBase` and its subclasses now take an `AbstractionPattern`
all the way down, and fixing up the visitor logic so that it derives appropriate
abstraction patterns for tuple elements, function arguments, and aggregate fields too.
This makes it so that type lowering is independent of the current generic context.
(Unfortunately, there are still places scattered across the code where we use the
current generic context in order to build abstraction patterns that we then feed
into type lowering, so we can't yet completely eliminate the concept.)
This then enables us to integrate substituted function type construction into type
lowering as well, since we can now lower a generic parameter type against an
abstraction pattern without that generic parameter having to be tied to the same
generic signature (or any generic signature at all, which in the case of a
substituted function type hasn't necessarily even been finalized yet.)
Tear out the hacks to pre-substitute opaque types before they enter the SIL type system.
Implement UnderlyingToOpaqueExpr as bitcasting the result of the underlying expression from the
underlying type to the opaque type.
The constraint solver support for the Swift 3 function type behavior
has been removed, so it's no longer possible to pun the same value as
both a function taking multiple parameters and a function taking a
single tuple argument.
This means the entire parameter list is no longer a target for
substitution as a single value, so the most general form of a function
value passes each parameter indirectly instead of passing a single
tuple parameter indirectly.
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
ground work for the syntactic bridging peephole.
- Pass source and dest formal types to the bridging routines in addition
to the dest lowered type. The dest lowered type is still necessary
in order to handle non-standard abstraction patterns for the dest type.
- Change bridging abstraction patterns to store bridged formal types
instead of the formal type.
- Improve how SIL type lowering deals with import-as-member patterns.
- Fix some AST bugs where inadequate information was being stored in
various expressions.
- Introduce the idea of a converting SGFContext and use it to regularize
the existing id-as-Any conversion peephole.
- Improve various places in SILGen to emit directly into contexts.
Introduce abstraction patterns for curried C-functions-as-methods for type lowering, and plumb the "foreign self parameter index" through call emission so that we emit the "self" parameter in the right position. This gets us handling C functions imported as methods with explicit swift_name attributes in simple, fully-applied cases. There's still more work to be done for properties, partial applications, and initializers introduced by extensions.
Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
When a dependent type is mapped into context, the result will either be
an archetype or a concrete type. The latter occurs if a same-type
constraint exists between the dependent type and the concrete type.
The logic to decide if a type should be passed directly or indirectly
was not handling this case if an interface type was passed down -- we
would just check if there was a class constraint present.
This resulted in mismatching conventions between an interface type and
its corresponding contextual type, which would trigger assertions.
Note that same-type constraints between generic parameters and concrete
types are still not supported for other reasons; the subject of the
constraint must still be an associated type of a generic parameter.
Fixes <rdar://problem/24687460>.
If an abstraction pattern has interface types in it, we
already enforce that it was constructed with a generic
signature.
This generic signature is only used to answer questions
about the abstraction pattern's own formal type, and
not with the substituted type.
So only put type lowering cache entries in the dependent
cache if they contain interface types in the substituted
type. Otherwise, if only the abstraction pattern has
interface types in it, the entry can live in the
independent cache, allowing it to be looked up without
a pushGenericContext() / popGenericContext() call.
For correctness, we now have to store the generic signature
in the type key as well. Subsequent changes should reduce
the size of the cache, by lowering fewer archetypes.
NFC, since nothing uses this for now.
When lowering the original unsubstituted type to check for parameters
and results being passed indirectly, be careful to map it to archetypes,
since the abstraction pattern's generic signature might not equal
M.Types.getCurGenericContext().
Also, don't use '==' to compare canonical interface types.
NFC for now, since this code is largely not exercised.
- isTypeParameter() -- check if this is an archetype or dependent
interface type.
- requiresClass() -- check if this is a class-constrained type
parameter.
The old isOpaque() check has been replaced by
(isTypeParameter() && !requiresClass(moduleDecl)).
This allows us to pass the ModuleDecl on down to
GenericSignature::requiresClass(), enabling the use of
interface types in abstraction patterns.
NFC for now.
Instead of bodging a representation of the SIL capture parameters for a closure into the formal type of closure SILDeclRefs, introduce those parameters in a separate lowering step. This lets us clean up some TypeLowering code that was tolerating things like SILBoxTypes and naked LValueTypes in formal types for nefarious ends (though requires some hacks in SILGen to keep the representation of curry levels consistent, which is something I hope to clean up next). This also decouples the handling of captures from the handling of other parameters, which should enable us to make them +0. For now, there should be NFC.
Probably SILGenPoly.cpp should be named SILGenThunk.cpp, but I'm saving
that for if I ever extract the duplication between bridging thunks and
re-abstraction thunks.
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
This commit reapplies r29266 with a conservative build fix
that disables ObjC property descriptors for @objc properties
that lack a getter. That should only be possible in SIL
files, because @objc should force accessors to be synthesized.
Arguably, Sema shouldn't be marking things implicitly @objc
in SIL files, but I'll leave that decision open for now.
Swift SVN r29272
