Support demangling for types nested within some simple extension contexts.
Still does not support nested types within constrained extensions that
involve same-type constraints among generic parameters, nor
deeply-nested types in extensions. However, it fixes
rdar://problem/40071688.
Extend the runtime's ability for evaluating generic requirements to
handle same-type requirements, demangling/substituting the name from
the generic requirement metadata.
Extend the support for mangled-name-to-type-metadata's handling of generic
types to handle nested types, including gathering type arguments from
parent contents and checking generic requirements.
Now that we have a suitable calling convention for the access function
of a generic nominal type descriptor with > 3 arguments, add support
for calling with an arbitrary number of generic arguments.
Support demangling bound generic types (e.g., Array<Int>) and forming
type metadata for them. For now, only support non-nested generic types
with up to three generic parameters.
Extend the protocol descriptor with a (space-separated) list of associated
type names, in the order of their requirements. Use this information in
the runtime to support lookup of associated type witnesses by name when
mapping a mangled name to a type and substituting generic parameters.
Extend _typeByMangledName with support for user-provided type parameter
substitutions, where type parameters that occur in the mangling can be
replaced with specific types.
Search through the new section containing Swift protocol descriptor
references to resolve protocols by mangled name. Use this
functionality to support protocol composition types within
_typeForMangledName.
Introduce a standard library/runtime entry point that produces type metadata
given a mangled name, based on the TypeDecoder logic lifted from the remote
mirrors library.
Implement support for tuple types as a proof-of-concept.
