This is to support dynamic function replacement of functions with opaque
result type.
This approach requires that all state is thrown away (that could contain the
old returned type for an opaque type) between replacements.
rdar://48887938
Also:
- additionally require the containing and overridden initializers are
designated, as that's the only case in which we should produce the '= super'
syntax in module interfaces
- Add notes to point out the locations of the overriden initializer when it's
not designated, and the corresponding parameter in that initializer when it
doesn't have a default argument to inherit.
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
This prevents opaque result types from propagating nontrivially into other declarations' types,
which may be confusing and create implementation complexities.
To represent the abstracted interface of an opaque type, we need a generic signature that refines
the outer context generic signature with an additional generic parameter representing the underlying
type and its exposed constraints. Opaque types also need to be keyed by their originating decl, so
that we can treat values of the same opaque type as the same. When we check a FuncDecl with an
opaque type specified as its return type, create an OpaqueTypeDecl and associate it with the
originating decl. (A representation for *types* derived from the opaque decl will come next.)
Previously, nearly all of the type vars for a key path component were dumped under the KeyPathExpr itself, whcih made them difficult to differentiate when debugging. Attach each one to “key path component #N -> function result” instead.
# Conflicts:
# lib/Sema/CSGen.cpp
ASTDumper doesn’t have any way to look up key path component types in the constraint solver, so they’re currently shown as null. This change adds a hook to look them up and looks in the key path component’s FunctionResult locator, which is where subscripts already keep their return type.
