This ensures that the trivial property descriptors is externally
accessible on targets like Windows which does not export symbols by
default. Thanks to Joe Groff for the pointer about the global aliases
for trivial property descriptors!
If a key path literal appears in a generic context with an existing context descriptor, this will allow us to
save some code size by not having to emit a separate GenericEnvironment descriptor.
This can happen when emitting an inlinable function in a resilient
module, because inlinable functions use the most conservative
access pattern.
This allows some earlier tests for keypaths inside inlinable
functions to pass IR emission, too.
An existing test used an external reference within the same module
to test external references; move this part to a separate test that
builds a separate module to correctly test this functionality.
Always use mangled type names to represent type metadata in keypath patterns.
For generic types, use the generic environment to pull substituted types
from the instantiation arguments.
Finishes the type metadata part of rdar://problem/38038799.
Extend the key-path pattern with a representation of the generic environment
of the key-path, which includes the generic parameters and generic
requirements of the environment.
When we emit "false" symbolic references to accesors for conformances or
type metadata, ensure that we end up with two-byte-aligned symbolic
references. This addresses a problem with ARM+Thumb compilation where the
low bit wasn't getting set for Thumb code.
Fixes rdar://problem/46067353.
When a type in keypath metadata is non-dependent, use a mangled type name
rather than a symbolic reference to an accessor function.
Part of rdar://problem/38038799.
Switch key path metadata over to mangled names for each of the places it
refers to either a type metadata accessor or a witness table accessor. For
now, the mangled name is a symbolic reference to the existing accessors.
Part of rdar://problem/38038799.
We were emitting relative references to entities that might be in
another translation unit. Use a GOT entry or thunk where appropriate.
Fixes <rdar://problem/45901706>.
Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
Use relative references instead of pointers so that the pattern can be true-const. Instead of trying
to instantiate a constant key path literal in-place, point to a cache variable that we can store
a pointer to the shared instance into when instantiated. Now that the pattern format has diverged
significantly from the instance format, simplify and refactor the instantiation code using a walker
for the pattern format instead of trying to reuse the code for working with instantiated instances.
rdar://problem/42674576
If we know a key path component can be accessed as a stored property, then we should also know whether it's a `let` or not, so it should be safe to encode this in the key path pattern. Stage this change in by changing the number of bits used to store in-line offsets, fixing up the parts of the key path implementation that assumed that it took up the entire payload bitfield.
Certain uses of protocols only formally need the requirement
signature, not any of the method requirements. This results in IRGen
seeing a protocol where none of the members have been validated except
the associated types. Account for this by allowing ProtocolInfo to
only contain the layout for the base protocols and associated types,
if requested.
Note that this relies on the layout of a witness table always putting
the "requirement signature part" at the front, or at least at offsets
that aren't affected by function requirements.
rdar://problem/43260117
When emitting fixed class metadata, we emit field offsets for all fields,
including those from superclasses, if any.
Get the ClassLayout for the correct class before looking up a field that
might potentially belong to a superclass. Soon, I'm going to slim down
ClassLayout instances to only store the fields belonging to the class
itself, removing the InheritedStoredProperites array altogether.
The resilient methods will all be keyed by their dispatch thunks, so for methods of local subclasses, we can use the offsets relative to the dynamic base as identifiers without having to adjust for that dynamic base.
Client code doesn't necessarily know the dispatch table indexes (and in time, there may not even be such a thing), and the dispatch thunk is a stable ABI artifact that can reliably uniquely identify the thing.
The other side of #17404. Since we don't want to generate up front key path metadata for properties/subscripts with no withheld implementation details, the client should generate a key path component that can be used to represent a key path component based on its public interface.
Client code can make a best effort at emitting a key path referencing a property with its publicly exposed API, which in the common case will match what the defining module would produce as the canonical key path component representation of the declaration. We can reduce the code size impact of these descriptors by not emitting them when there's no hidden or possibly-resiliently-changed-in-the-past information about a storage declaration, having the property descriptor symbol reference a sentinel value telling client key paths to use their definition of the key path component.
Most of the work of this patch is just propagating metadata states
throughout the system, especially local-type-data caching and
metadata-path resolution. It took a few design revisions to get both
DynamicMetadataRequest and MetadataResponse to a shape that felt
right and seemed to make everything easier.
The design is laid out pretty clearly (I hope) in the comments on
DynamicMetadataRequest and MetadataResponse, so I'm not going to
belabor it again here. Instead, I'll list out the work that's still
outstanding:
- I'm sure there are places we're asking for complete metadata where
we could be asking for something weaker.
- I need to actually test the runtime behavior to verify that it's
breaking the cycles it's supposed to, instead of just not regressing
anything else.
- I need to add something to the runtime to actually force all the
generic arguments of a generic type to be complete before reporting
completion. I think we can get away with this for now because all
existing types construct themselves completely on the first request,
but there might be a race condition there if another asks for the
type argument, gets an abstract metadata, and constructs a type with
it without ever needing it to be completed.
- Non-generic resilient types need to be switched over to an IRGen
pattern that supports initialization suspension.
- We should probably space out the MetadataStates so that there's some
space between Abstract and Complete.
- The runtime just calmly sits there, never making progress and
permanently blocking any waiting threads, if you actually form an
unresolvable metadata dependency cycle. It is possible to set up such
a thing in a way that Sema can't diagnose, and we should detect it at
runtime. I've set up some infrastructure so that it should be
straightforward to diagnose this, but I haven't actually implemented
the diagnostic yet.
- It's not clear to me that swift_checkMetadataState is really cheap
enough that it doesn't make sense to use a cache for type-fulfilled
metadata in associated type access functions. Fortunately this is not
ABI-affecting, so we can evaluate it anytime.
- Type layout really seems like a lot of code now that we sometimes
need to call swift_checkMetadataState for generic arguments. Maybe
we can have the runtime do this by marking low bits or something, so
that a TypeLayoutRef is actually either (1) a TypeLayout, (2) a known
layout-complete metadata, or (3) a metadata of unknown state. We could
do that later with a flag, but we'll need to at least future-proof by
allowing the runtime functions to return a MetadataDependency.
A public subscript might have generic indexes that aren't unconditionally Hashable, or might use indexes that are retroactively made Hashable, so the property descriptor on the implementer's side can't always resiliently provide this information to the final instantiated KeyPath.
The key path pattern needs to include a reference to the external descriptor, along with hooks for lowering its type arguments and indices, if any. The runtime will need to instantiate and interpolate the external component when the key path object is instantiated.
While we're here, let's also reserve some more component header bytes for future expansion, since this is an ABI we're going to be living with for a while.
This will allow key paths to resiliently reference public properties from other binaries by referencing a descriptor vended by the originating binary. NFC yet, this just provides printing/parsing/verification of the new component.
