Potential archetypes can resolve to either an associated type or a
typealias. Generalize the latter to "any concrete type", both because
the current implementation is unnecessarily narrow (typealiases aren't
actually special in this regard) and to get us closer to handling
lookups via superclass constraints when resolving these types.
Once we're finalizing same-type-to-concrete and superclass
constraints, replace any unresolved DependentMemberTypes with their
resolved counterpairs. This allows us to simplify
DependentGenericTypeResolver, which only builds unresolved
DependentMemberTypes now, and eliminates the penultimate use of
ArchetypeResolutionKind::AlwaysPartial.
If they're considered explicit, requirement inference will complain when
it infers X: SomeProtocol for some concrete type X.
Fixes SR-4693, rdar://problem/31819616
Recursive concrete and superclass constraints are detected
per-equivalence-class; record them that way.
Use that information to drop recursive concrete and superclass
constraints from the resulting signature, which frees the canonical
generic signature builder from having to worry about such recursive
constraints. This eliminates the invalid-code crashes introduced in
the prior commit that disabled finalization for the canonical GSBs, as
well as fixing one other random crash-on-invalid.
The GenericSignatureBuilder requires `finalize()` to be called before a
generic signature can be retrieved with `getGenericSignature()`. Most of the former isn’t strictly needed unless you want a generic signature, and the
latter is potentially expensive. `computeGenericSignature()` combines the two
operations together, since they are conceptually related. Update most of the
callers to the former two functions to use `computeGenericSignature()`.
Archetype anchors are (re-)computed often, but shouldn't change all
that much. Cache them in the equivalence class for a ~15% speedup
type-checking the standard library.
Put the archetype anchor consistency checking behind a separate
it is really expensive: turning this checking off shaves 5s off the
type-checking time of the standard library in my Release+Asserts build
(~23% speedup).
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
I don't fully understand why, but this logic here is redundant
because we end up adding layout constraints implied by types in
the inheritance clause anyway.
Infer same-type requirements among same-named associated
types/typealiases within inherited protocols. This is more staging; it
doesn't really have teeth until we stop wiring together these types as
part of lookup.
Introduce a warning about redeclaring the associated types from an
inherited protocol in the protocol being checked:
* If the new declaration is an associated type, note that the
declaration could be replaced by requirements in the protocol's
where clause.
* If the new declaration is a typealias, note that it could be
replaced by a same-type constraint in the protocol's where clause.
There's a more pervasive issue here that needs further study;
essentially, we can end up with self-derived sources getting
reinjected later, and will either need to avoid that reinjection or
need to expand what this localized hack does, filtering out
self-derived constraints when we enumerate requirements.
This stops after 5 recurrences of the same associated type. It is a
gross hack and a terrible idea, here as a placeholder to prevent us
from running off the rails in ill-formed code. This will go away when
we get further along the path with recursive protocol constraints.
When we’re determining what type should be used to key a ProtocolRequirement based on the source’s potential archetype and the target’s potential archetype, use potential archetype identity (==) rather than equivalence-class membership to cover the basis case. This ensures that interesting identity relationships in the enclosing context (e.g., the current GenericSignatureBuilder) don’t cause us to compute incorrect stored types.
When computing the connected components of within an equivalence class (based on derived same-type requirements), we might need derived-via-concrete constraints to maintain connectedness of the larger graph. Therefore, delay their removal until after we’ve computed connected components.
Now that we detect recursion based on repetition within the potential
archetypes, we no longer rely on passing down "visited" sets to
detect/diagnose recursion. Remove them.
Recursive protocol conformances still aren't functional, so reinstate
some checking for recursive protocol conformances. It doesn't catch
everything that the previous version did---but we don't crash on such
cases anymore, either.
Rather than detecting recursion and bailing early, delay requirements
that would form recursive types. Note that we aren't actually
processing them later.
Teach addInheritedRequirements() to take an UnresolvedType, so the
requirements it adds can be delayed if needed. More importantly, teach
the primary caller (addConformanceRequirement) not to use
getNestedType directly; instead, form an appropriate Type and let the
type-resolution machinery handle it.
Apply the same logic used for self-derived conformance constraints,
where we drop constraints derived from concrete conformances, to the
remaining kinds of constraints covered by isSelfDerivedSource().
Reimplement isSelfDerivedSource() in terms of the new
visitPotentialArchetypesAlongPath(). Aside from being clearer and
shorter, this formulation eliminates some hackery (the direct
"NestedType" lookup) that was mostly masking a bug in
updateNestedTypeForConformance() where we created a
nested-type-name-match source with an incorrect source for the
purposes of concretizing the nested type.
Fixes SR-4458 / rdar://problem/31375569.
Factor out a core operation of RequirementSource that walks the
potential archetypes from the root to the end of the path, enumerating
each partial RequirementSource along with the potential archetype to
which it applies. Use it for getting the final archetype to which the
RequirementSource refers, as well as simplifying the self-derived
check for conformance requirements.
When an otherwise abstract conformance constraint is derived from a
concrete conformance, retain the abstract conformance by removing the
requirement source that involves the concrete conformance. This
eliminates our reliance on the concrete conformance, which is not
retained as part of the generic signature.
Fixes rdar://problem/31163470 and rdar://problem/31520386.
Rather than hardcoding all of the substitution logic for requirements
in the RequirementEnvironment constructor, harden and re-use the
GenericSignatureBuilder's substitution logic instead.
When a requirement mentions a concrete type, that type might utter
other types (e.g., Set<T>) that infer requirements (here, T:
Hashable). Perform requirement inference for such types.
Part of rdar://problem/31520386.
There were various problems with layout constraints either
being ignored or handled incorrectly. Now that I've exercised
this support with an upcoming patch, there are some fixes
here.
Also, introduce a new ExistentialLayout::getLayoutConstriant()
which returns a value for existentials which are class-constrained
but don't have a superclass or any class-constrained protocols;
an example would be AnyObject, or AnyObject & P for some
non-class protocol P.
NFC for now, since these layout-constrained existentials cannot
be constructed yet.
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
We were putting conformance requirements on the representative of the
equivalence class, rather than directly on the potential archetype on
which the conformance requirement was specified. This violates the
invariant used when forming protocol-requirement sources that we never
reseat a requirement onto the representative (which would
have become a problem when implementing recursive protocol
constreaints) as well as masking a GSB idempotency issue that comes
from same-type requirements where the right-hand side was not
guaranteed to refer to the archetype anchor *within* that subcomponent.
