They would think the type 'addr_t' is defined in the standard library
because it has the same name format with the types in <cstdint>. In
addition, the definition conflicts in Cygwin which defines it differently
in the system library.
This adds various MetadataReader methods to support closure layout:
- Reading generic arguments from metadata
- Reading parent metadata
- Reading capture descriptor from heap metadata
To a large extent, this is not currently taken advantage of, because
SILGen always wraps address-only captures in SIL box types.
Tests are in the next patch.
Implement the ReflectionContext's implementation of:
swift_reflection_projectExistential.
First, we get the type info of the existential typeref - it should be a
record type info. If it's a class existential, it has trivial layout:
the first word is a pointer to the class instance. Otherwise, if the
value fits in the 3-word buffer of the existential container, it
trivially is also at the start of the container. Otherwise, the value is
off in a heap box somewhere, but the first word of the container is a
pointer to that box.
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.
This tool should test the usage from SwiftRemoteMirror dylib and
the C API, since that is the public interface from which we're
vending the remote reflection functionality.
This API will take a pointer to the start of an existential
container and its typeref and provide a typeref for its
instance type and the address to the start of the instance's
data.
This has a dummy implementation that returns false for now.
swift_reflection_createReflectionContext was defaulting to C++ mangling
because the declaration under extern C in the header didn't match
its signature.
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>.
Memory readers on the C-side of the API may actually have an object-
oriented design, so they may want to pass an instance to revive
when callbacks make it to the other side of the API boundary.
In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
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.
Although the SwiftRemoteMirror library targets a specific architecture,
it's still an external runtime, so treat it as such. The InProcess template
argument is reserved for truly in-process reflection in the Runtime.
