Getting metadata from a metatype source just means loading from an offset;
with a reference source we have to dereference the isa pointer first.
Thanks to @bitjammer for pointing out this was broken.
Lowered function types appear in capture descriptors.
For now, we completely punt on demangling parameters and
results, and just hackishly map the SIL function type
representation to an AST function type representation.
This is good enough, because all we care about is whether
we have a raw function pointer, raw function pointer with
context, or a block.
- Fix caller/callee confusion, and use the right SIL function type
for obtaining the generic signature.
- Correctly interpret the NecessaryBindings structure and the
substitutions therein.
- Fix alignment for capture and builtin type descriptors
- Put capture descriptor typerefs in the correct section
Add new SIL-level tests to precisely trigger various scenarios.
Rather than collection nominal type and extension decls and emit
reflection metadata records in one go, we can emit them as they
are encountered and instead collection builtin types referenced
by those at the end.
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>.
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 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.
Previously we would pre-process the same input files in the ObjC
and non-ObjC tests. This made the tests difficult to update because
the output of one was a subset of the other, and only one of the
two tests would run on any given platform.
Instead, let's just put the Objective-C tests in their own test
and input files.
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.
When creating a TypeRef from metadata, we have a parent pointer
handy, and construct the TypeRef directly, so there's no need
to mutate the TypeRef after the fact.
When demangling a TypeRef from a string, the mangling encodes
the parent module or type context, so we can set it when
constructing the TypeRef there too.
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-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.
Once an unsubstituted typeref for a field is built, we substitute
`GenericTypeParameterTypeRef`s with concrete ones built from the generic
arguments of concrete bound generic metadata.
During that process, if we run into a `DependentMemberTypeRef` (e.g.
something of type T.Index), we substitute the base (T) using the current
list of substitutions, and then resolve what `Index` is for the base
using the associated type metadata in the 'assocty' data section.
Similiar to the change to field reflection metadata, don't use the
interface for the key of associated type lookup, because the nominal
type descriptors don't include generics in their mangled name strings.
Nominal type descriptors use declared types for their mangled names,
so we need to use them when scanning the fieldmd section for a
matching record. This is fine because the descriptor can tell us
about the type's generics. Individual field records continue to use
the interface type.
These likely don't have Swift type metadata but might be useful to
record or instantiate based on what kind of metadata is encountered for
the sake of memory tools.
