Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
This memoizes the result, which is fine for all callers; the only
exception is open existential types where each new open existential
now explicitly gets a unique generic environment, allocated by
calling GenericEnvironment::getIncomplete().
The fix for <https://bugs.swift.org/browse/SR-617> introduced
a new kind of requirement environment where 'Self' remains a
generic parameter, but receives a class constraint, instead of
becoming fully concrete.
As before, we would form the synthetic signature by taking
the generic signature of the requirement, and substituting it
the new 'Self' type.
However, whereas previously the 'Self' type was always concrete
and any DependentMemberTypes in the requirement's signature
would become concrete type references, with a class-constrained
'Self' the DependentMemberTypes remain.
Apparently, the GSB cannot handle DependentMemberTypes where
the base is class-constrained.
Work around this by ensuring that we add a conformance constraint
for the 'Self' parameter to the protocol in question, which
allows the DependentMemberTypes to be correctly resolves once
the conformance is made concrete by a superclass constraint.
The FIXME comment being removed here references crashes which
no longer seem to reproduce, so I'm assuming some underlying
GSB issues got fixed and the FIXME is clearly no longer necessary.
However, I still consider this fix somewhat unsatisfying, because
it is not clear if there's some deeper flaw in how the GSB
models superclass constraints. It might resurface again in the
future.
Fixes <rdar://problem/39419121>, <https://bugs.swift.org/browse/SR-7428>.
Before this patch, the use of GenericSignature::getSubstitutionMap to
create a substitution map would result in some generic parameters being
completely elided (well, being mapped to concrete types causing a
->castTo<GenericTypeParamType>() to crash). This patch changes that to
just do the reindexing of the type parameters directly, without trying
to be smart with more contextual information (i.e. τ_0_0 -> τ_1_0, even
if there's a τ_0_0 == Int requirement).
Fixes rdar://problem/37291254 and SR-6990.
Move the rest of associated type inference into the new source file,
and split RequirementEnvironment into its own AST-level header, because it
can be re-used and has no ties to the type checker.
