Closure context layout will depend on the instance itself as well
as the isa pointer, because instead of instantiating metadata for
closures that capture generic parameters, we store the substitutions
inside the context itself.
For classes, this entry point just reads the isa pointer, applies
the isa mask and proceeds down the metadata path.
For now, the only the latter is hooked up.
Also, use the instance layout entry point in swift-reflection-test,
so that we can dump the layout of a class instance and not the
lowering of the reference value.
- Improper handling of read() returning an incomplete read
- Update SwiftReflectionTest library for new builtin types section
Only tested manually so far; automated tests coming soon.
along with the boilerplate macro. This allows one to create TypeRefs
with either the builder or via the static methods, so long as a builder
argument is supplied so uniquing caches can be checked.
rdar://problem/25924875
We'd like to be able to compare TypeRefs with pointer equality,
but we can't link LLVMSupport, so make a lightweight TypeRefID
like FoldingSetID, that only supports the input types necessary
to unique TypeRefs.
rdar://problem/25924875
The metadata system doesn't actually unique based on labels
correctly, so the test case has to play some games. That's
something that will be easier to fix when there are fewer
clients poking at the internals of the metadata runtime.
The thin vs thick distinction is handled a little awkwardly. Instead of
passing around abstraction patterns, we add a "must be thick" bit to
MetatypeTypeRef, and thicken substitutions (to handle T; T := C.Type)
and the result of a subtitution (to handle T.Type; T := C).
With the exception of enums this completes <rdar://problem/25738849>.
For now, just enough for lowering.
Perhaps we should have a way to always just get this information
from metadata instead, since protocol metadata is always static
and not instantiated.
This would require the static "object file" interface used by
swift-reflection-dump to take a callback for symbol lookup.
Also add slightly inaccurate lowering for the special case of an
optional of a reference type. I need to rethink the approach for
extra inhabitants and enums, but this suffices for now.
For convenience when reading looking at heap closure metadata.
Also move the capture typerefs above the metadata sources, since
they're more likely to be accessed than generic metadata sources.
Now we can discern the types of values in heap boxes at runtime!
Closure reference captures are a common way of creating reference
cycles, so this provides some basic infrastructure for detecting those
someday.
A closure capture descriptor has the following:
- The number of captures.
- The number of sources of metadata reachable from the closure.
This is important for substituting generics at runtime since we
can't know precisely what will get captured until we observe a
closure.
- The number of types in the NecessaryBindings structure.
This is a holding tank in a closure for sources of metadata that
can't be gotten from the captured values themselves.
- The metadata source map, a list of pairs, for each
source of metadata for every generic argument needed to perform
substitution at runtime.
Key: The typeref for the generic parameter visible from the closure
in the Swift source.
Value: The metadata source, which describes how to crawl the heap from
the closure to get to the metadata for that generic argument.
- A list of typerefs for the captured values themselves.
Follow-up: IRGen tests for various capture scenarios, which will include
MetadataSource encoding tests.
rdar://problem/24989531
Create a builder divorced from the ReflectionContext so that
MetadataSources can be created in other contexts, such as emitting
private heap metadata during IRGen, where we'll have to record the
layout of captures and how to get metadata for generic arguments in
order to construct typerefs of the captures, etc.
Add Parent, Metadata capture, and Impossible metadata sources.
Now that we can parse and substitute typerefs, and look up field
types, we finally have enough infrastructure in place to do some
basic layout of struct and tuple types from within the Reflection
library.
To facilitate testing, swift-reflection-dump now accepts multiple
-binary-filename flags, allowing types defined in the standard
library to be looked up.
More detailed end-to-end tests will come once I finish the
typeref-to-metadata builder.
We want to look at the nominal type kind before lowering any field
types, since the lowering of a class type does not depend on any
of its field types at all.
Tested by upcoming type lowering patch, for now NFC.
ReflectionContext is now solely concerned with converting runtime
metadata in a remote address space into a TypeRef.
TypeRefBuilder now knows how to parse reflection metadata, and
in particular look up associated type witnesses. This decouples
the TypeRef substitution code from the ReflectionContext. Now
substitution only needs a TypeRefBuilder, which means the code
is no longer templated, and can be moved from TypeRef.h to
TypeRef.cpp.
This also allows the upcoming TypeRef lowering code to live in
a source file instead of headers.
ReflectionContext is getting too large, and having to thread a
<Remote> template parameter through all code that wants to construct
typerefs is getting tricky. This is the first patch in a refactoring
to move some stuff out of ReflectionContext.
