This commit just introduces the instruction. In a subsequent commit, I am going
to add support to SILGen to emit this. This ensures that when we assign into a
tuple var we initialize it with one instruction instead of doing it in pieces.
The problem with doing it in pieces is that when one is emitting diagnostics it
looks semantically like SILGen actually is emitting code for initializing in
pieces which could be an error.
Ensuring that conformances to such protocols must have their type metadata always emitted into the binary, regardless of wheter they are used or `public`.
It eases reading the code. Updated a few tests that were overly strict
(requiring registers to be named with only numbers) to accept more
register names.
Extend function type metadata with an entry for the thrown error type,
so that thrown error types are represented at runtime as well. Note
that this required the introduction of "extended" function type
flags into function type metadata, because we would have used the last
bit. Do so, and define one extended flag bit as representing typed
throws.
Add `swift_getExtendedFunctionTypeMetadata` to the runtime to build
function types that have the extended flags and a thrown error type.
Teach IR generation to call this function to form the metadata, when
appropriate.
Introduce all of the runtime mangling/demangling support needed for
thrown error types.
When metadata record for a generic type is locally cached as ::Complete,
the metadata is known to be complete in that scope. If it's for a
generic type, being complete means that all of its recursive generic
arguments are also complete.
Previously, though, that fact was not exploited. So a metadata record
for such an argument which was originally obtained via an incomplete
request would remain cached in that incomplete state even when a generic
type in which it appeared as a generic argument was cached as complete.
At worst, the result was a runtime call (checkMetadataState) to promote
the complete the metadata record for the recursive argument.
Here, when a bound generic type's metadata is locally cached as
complete, its recursive generic arguments are visited; for each such
type for which a metadata record is already locally cached, the
preexisting record is recached as complete.
When building complex projects, there may cases of static libraries
which expose `@inlinable` functions which reference functions from
dynamically linked dependencies. In such a case, we need to consider the
provenance of the `function_ref` when determining the DLL storage for
linkage. We would previously use the deserialised metadata on the
`SILFunction` as there are entities where the `DeclContext` may not be
deserialised. However, this leaves us in a state where we are unable to
determine the actual provenance correctly in some cases. By simply
accessing the parent module directly from the `SILFunction` we ensure
that we properly identify the origin of the function allowing us to
query the DLL storage property. This further allows us to remove the
extra storage required for whether the `SILFunction` is statically
linked.
Swift methods can be called from Objective-C without a vtable
load, and more importantly without emitting an `llvm.type.checked.load`
instruction. These are effectively virtual callsites that are not
visible to the VFE logic in GlobalDCE.
To to safely enable swift-vfe we must prevent vtables whose functions
are callable from Objective-C from being eliminated.
To do this we ensure such vtables have public vcall_visibility, which
indirectly prevents GlobalDCE from stripping them.
The Swift and LLVM function mergers were disabled when Swift VFE or WME
are enabled because the function merger did not respect metadata on
calls to `llvm.type.checked.load`. This is no longer the case,
so we can turn these passes back on.
This type will become the corresponding type that is resolved for an
`InverseTypeRepr`. This kind of type is not expected to appear past type
checking (currently, not even past requirement lowering!).
