Sema allows you to pass type-pinning parameters into an extension of an Objective-C generic class, but IRGen did not properly handle erasing these types to existential types in runtime metadata. This commit corrects that mistake.
This adjusts the IRGen layer to accommodate the Windows linking model.
We assume dynamic linking by default. The static linking is enabled by
passing `-static` to the driver, which forwards it to the frontend when
building the module statically. This has already been required when
generating libraries, however, the non-Windows targets are more
forgiving and let it work. On those platforms, using this hint would
allow for more efficient code generation, reducing load times and some
runtime penalties from the PLT and GOT references formed to symbols
which are module local.
This corrects static linking on Windows, which is one of the last few
items that are missing on Windows. It also takes advantage of the hint
for the one peculiar difference between Windows and non-Windows:
protocol conformances that span module boundaries are not available as a
constant. However, when statically linking, we can enable those
conformances to be statically resolved. This should enable the last
known pattern to work when using static linking.
This support requires further work in the Swift Package Manager to
actually enable building libraries properly. However, when building
with CMake, this should be sufficient to enable static linking.
Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
EmitPolymorphicArguments puts the extra sources before the unfulfilled
requirements into the explosion. The NecessaryBindings instance must
have the type parameters in the same order. Previously, though, they
were added after enumerating unfulfilled requirements. Here, they are
added _before_ enumerating, matching the ordering of
EmitPolymorphicArguments.
rdar://73742483
Resilient witness tables and resilient class vtables are built from
descriptors. Make sure we reference the AsyncFunctionPointer of a
method implementation, and not the implementation itself, if the
method is async.
Part of rdar://problem/73625623.
Previously, when saving NecessaryBindings for an async function, if a
type that was passed-in happened to be an archetype, a lookup for that
type's conformance would always be done. However, that lookup was not
always necessary or possible such as in the case where both the metadata
and the witness table were provided to the function in an async context.
Here, that is fixed by using the conformance that was seen when
constructing the NecessaryBindings if one is available.
rdar://problem/72397303
NecessaryBindings are used by both async functions and partial apply
forwarders. The latter are able to avoid bindings in some cases because
a new function is generated where the information that would otherwise
be available in the bindings can be made available. That is not the
case for async functions. A generic async function requires all of the
metadata and witness tables be passed along to it: unlike a partial
apply forwarder it isn't in any way specialized so this information
can't be recovered.
Previously, metadata bindings were always passed along to async
functions. However, destructuring that can be done for partial apply
forwarders was still being applied. This resulted in an inappropriate
and unexpected number of bindings in NecessaryBindings.
Here, that destructuring is avoided for metadata passed to async
functions.
Now, the full metadata required by async functions are passed along to
them as necessary.
rdar://problem/71816041
An AsyncFunctionPointer, defined in Task.h, is a struct consisting of
two i32s: (1) the relative address of the async function and (2) the
size of the async context to be allocated when calling that function.
Here, such structs are emitted for every async SILFunction that is
emitted.
Previously, NecessaryBindings used a SetVector to store the
GenericRequirements that it accumulates. That was a problem for the
layout of async contexts where it is possible for the same generic
argument to be repeated. Meanwhile, that is correct for partial
application forwarders where there is a single thunk for every partial
apply and consequently the bindings can be packed in without
duplication.
Here, a SetVector is used only when the NecessaryBindings are for
partial apply forwarders. When the NecessaryBindings are instead for
async functions, a SmallVector is used.
Previously, EmitPolymorphicParameters dealt directly with an Explosion
from which it pulled values. In one place, there was a conditional
check for async which handled some cases. There was however another
place where the polymorphic parameter was pulled directly from the
explosion. That missed case resulted in attempting to pull a
polymorphic parameter directly from an Explosion which contains only a
%swift.context* per the async calling convention.
Here, those parameters are now pulled from an EntryPointArgumentEmission
subclasses of which are able to provide the relevant definition of what
pulling a parameter means.
rdar://problem/70144083
By default, emitTypeMetadataRef does a blocking request for complete
metadata, which is the right thing to do for most purposes in IRGen.
Unfortunately, it's actively dangerous in code that can be called
during metadata completion, like an associated conformance accessor,
because it can cause artificial dependency cycles that the runtime
isn't equipped to detect, much less solve.
This is a partial fix for rdar://69901318, which also exposes a bad
metadata access path that seems to be causing an artificial problem.
Previously, the AsyncContextLayout did not make space for the trailing
witness fields (self metadata and self witness table) and the
AsyncNativeCCEntryPointArgumentEmission could consequently not vend
these fields. Here, the fields are added to the layout.
Previously, the polymorphic arguments were being discarded. Here, that
situation is improved by pulling the polymorphic arguments out of the
explosion when having the polymorphic parameters via the
NecessaryBindings instance. In order to eanble that, an overload of
NecessaryBindings::save is added which takes an explosion and asserts
that the polymorphic parameter pulled from the explosion matches with
the polymorphic parameter in the NecessaryBindings instance.
Here, the following is implemented:
- Construction of SwiftContext struct with the fields needed for calling
functions.
- Allocating and deallocating these swift context via runtime calls
before calling async functions and after returning from them.
- Storing arguments (including bindings and the self parameter but not
including protocol fields for witness methods) and returns (both
direct and indirect).
- Calling async functions.
Additional things that still need to be done:
- protocol extension methods
- protocol witness methods
- storing yields
- partial applies
This became necessary after recent function type changes that keep
substituted generic function types abstract even after substitution to
correctly handle automatic opaque result type substitution.
Instead of performing the opaque result type substitution as part of
substituting the generic args the underlying type will now be reified as
part of looking at the parameter/return types which happens as part of
the function convention apis.
rdar://62560867
`@differentiable` attribute on protocol requirements and non-final class
members now produces derivative function entries in witness tables and vtables.
This enables `witness_method` and `class_method` differentiation.
Existing type-checking rules:
- Witness declarations of `@differentiable` protocol requirements must have a
`@differentiable` attribute with the same configuration (or a configuration
with superset parameter indices).
- Witness table derivative function entries are SILGen'd for `@differentiable`
witness declarations.
- Class vtable derivative function entries are SILGen'd for non-final
`@differentiable` class members.
- These derivative entries can be overridden or inherited, just like other
vtable entries.
Resolves TF-1212.
* Use in_guaranteed for let captures
With this all let values will be captured with in_guaranteed convention
by the closure. Following are the main changes :
SILGen changes:
- A new CaptureKind::Immutable is introduced, to capture let values as in_guaranteed.
- SILGen of in_guaranteed capture had to be fixed.
in_guaranteed captures as per convention are consumed by the closure. And so SILGen should not generate a destroy_addr for an in_guaranteed capture.
But LetValueInitialization can push Dealloc and Release states of the captured arg in the Cleanup stack, and there is no way to access the CleanupHandle and disable the emission of destroy_addr while emitting the captures in SILGenFunction::emitCaptures.
So we now create, temporary allocation of the in_guaranteed capture iduring SILGenFunction::emitCaptures without emitting destroy_addr for it.
SILOptimizer changes:
- Handle in_guaranteed in CopyForwarding.
- Adjust dealloc_stack of in_guaranteed capture to occur after destroy_addr for on_stack closures in ClosureLifetimeFixup.
IRGen changes :
- Since HeapLayout can be non-fixed now, make sure emitSize is used conditionally
- Don't consider ClassPointerSource kind parameter type for fulfillments while generating code for partial apply forwarder.
The TypeMetadata of ClassPointSource kind sources are not populated in HeapLayout's NecessaryBindings. If we have a generic parameter on the HeapLayout which can be fulfilled by a ClassPointerSource, its TypeMetaData will not be found while constructing the dtor function of the HeapLayout.
So it is important to skip considering sources of ClassPointerSource kind, so that TypeMetadata of a dependent generic parameters gets populated in HeapLayout's NecessaryBindings.
In order to allow this, I've had to rework the syntax of substituted function types; what was previously spelled `<T> in () -> T for <X>` is now spelled `@substituted <T> () -> T for <X>`. I think this is a nice improvement for readability, but it did require me to churn a lot of test cases.
Distinguishing the substitutions has two chief advantages over the existing representation. First, the semantics seem quite a bit clearer at use points; the `implicit` bit was very subtle and not always obvious how to use. More importantly, it allows the expression of generic function types that must satisfy a particular generic abstraction pattern, which was otherwise impossible to express.
As an example of the latter, consider the following protocol conformance:
```
protocol P { func foo() }
struct A<T> : P { func foo() {} }
```
The lowered signature of `P.foo` is `<Self: P> (@in_guaranteed Self) -> ()`. Without this change, the lowered signature of `A.foo`'s witness would be `<T> (@in_guaranteed A<T>) -> ()`, which does not preserve information about the conformance substitution in any useful way. With this change, the lowered signature of this witness could be `<T> @substituted <Self: P> (@in_guaranteed Self) -> () for <A<T>>`, which nicely preserves the exact substitutions which relate the witness to the requirement.
When we adopt this, it will both obviate the need for the special witness-table conformance field in SILFunctionType and make it far simpler for the SILOptimizer to devirtualize witness methods. This patch does not actually take that step, however; it merely makes it possible to do so.
As another piece of unfinished business, while `SILFunctionType::substGenericArgs()` conceptually ought to simply set the given substitutions as the invocation substitutions, that would disturb a number of places that expect that method to produce an unsubstituted type. This patch only set invocation arguments when the generic type is a substituted type, which we currently never produce in type-lowering.
My plan is to start by producing substituted function types for accessors. Accessors are an important case because the coroutine continuation function is essentially an implicit component of the function type which the current substitution rules simply erase the intended abstraction of. They're also used in narrower ways that should exercise less of the optimizer.
