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.
- 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.
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 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.
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.
The compiler is generally free to not include pointers to metadata in
heap boxes, which are used for closure captures, if it knows you can get
to metadata through some other path. These MetadataSource classes will
describe a sequence of steps to get to metadata at runtime.
In the short term, this will be useful for describing the layout of
function/closure capture contexts, which can vary depending on what is
captured.
We will be handing pointers to typerefs over the SwiftRemoteMirrors C
API boundary, at which point it is unclear who will hold onto a shared
pointer. The useful lifetime of a typeref is tied to the
ReflectionContext for which they were created anyway so, when it goes
away, all of those typerefs can go away anyway.
We can't use LLVM's bump-pointer allocator here because we only build
the Support library for the host. As a compromise, stuff new typeref
pointers into a vector pool, where they will be taken down during
ReflectionContext's destructor.
Just drop labels when demangling TypeRefs. This is OK for now
since labels do not affect layout.
Vararg tuple types cannot appear directly as the type of
storage, however they can appear in function input types, and
therefore must be minimally supported. Since we don't plan on
doing function call reflection just yet, this doesn't matter
for now, but again we need to not crash.
With this patch, all TypeRefs in the Swift standard library now
successfully demangle and print.
swift-reflection-dump, a host-side tool, requires this library that
normally builds for the configured platform. So, if the host platform
isn't configured to build for some reason, swift-reflection-dump will
fail to link.
swift-reflection-test is now the test that forks a swift executable
and performs remote reflection, making it runnable on other targets,
such as the iOS simulator.
swift-reflection-dump is now a host-side tool that dumps the remote
reflection sections for any platform binary and will continue to
link in LLVM object file support.
This necessitates finally moving lib/Refleciton into stdlib/public,
since we're linking target-specific versions of the test tool and
we would eventually like to adopt some of this functionality in
the runtime anyway.
