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.
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.
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.
