In some circumstances, we could end up growing increasingly-nested
potential archetypes due to a poor choice of representatives and
anchors. Address this in two places:
* Always prefer to use the potential archetype with a lower nesting
depth (== number of nested types) to one with a greater nesting
depth, so we don't accumulate more nested types onto the
already-longer potential archetypes, and
* Prefer archetype anchors with a lower nesting depth *except* that we
always prefer archetype anchors comprised of a sequence of
associated types (i.e., no concrete type declarations), which is
important for canonicalization.
Fixes SR-4757 / rdar://problem/31912838, as well as a regression
involving infinitely-recursive potential archetypes caused by the
previous commit.
Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:
* Always store a ProtocolConformanceRef in via-superclass and
via-concrete requirement sources, so we never lose this information.
* When concretizing a nested type based on its parent, use the
via-concrete conformance information rather than performing lookup
again, simplifying this operation considerably and avoiding
redundant lookups.
* When adding a conformance requirement to a potential archetype that
is equivalent to a concrete type, attempt to find and record the
conformance.
Fixes SR-4295 / rdar://problem/31372308.
Rather than abusing the "superclass" requirement source with a null
protocol conformance, introduce a separate "structurally derived"
requirement source kind for structurally-derived requirements that
don't need any additional information, e.g., the class layout
requirement derived from a superclass requirement.
NestedTypeUpdate was mostly just the internal name for
ArchetypeResolutionKind, but the translation was a bit lossy and there
was no point in having separate enums. Standardize on
ArchetypeResolutionKind, adding a new case (WellFormed) to capture the
idea that we can create a new potential archetype only when we know
there is a nested type with that name---and avoid creating unresolved
potential archetypes.
Rather than performing typo correction at the very end of finalize(),
do it as part of delayed requirement handling when we cannot otherwise
make progress. This is a cleaner way to cope with typo correction that
gives us a better chance of getting to a sane result.
Fixes rdar://problem/31048352 by eliminating the need for tracking the
number of unresolved potential archetypes altogether. Fixes
rdar://problem/32077627.
Whenever we form a potential archetype that is unresolved (because it
names a member wasn't known at the time the potential archetype was
formed), create a corresponding delayed requirement to resolve the
potential archetype. This ensures that all potential archetypes get a
chance to be resolve, fixing the
nested type should have matched associated type
assertion in rdar://problem/31401161 (and others).
DelayedRequirements were using the general RequirementKind, which was
at best an approximation (we smoothed over the difference between
Superclass and Conformance requirements). Split out the Kind into its
own type, so we can extend it with GSB-specific kinds.
When we infer a requirement from the result type of a function, don't
warn if that requirement was also stated explicitly. This has been a
point of confusion since we introduced the redundancy warnings,
because users don't consider to result type to be an "input" to the
function in the way the compiler does. So, while technically it is
"correct" to warn, it's unintuitive---so stop.
Fixes SR-5072 / rdar://problem/31357967.
The previous commit tightened up our choice of requirement sources for
superclass and layout constraints, but always assumed a match
existed. In cases where it does not, don't fail; rather, use an
abstract source, which we do elsewhere when we're synthesizing
requirements.
This is a defensive approach to cope with cases where we might not
have precisely the same value within one of our recorded
constraints. This currently only occurs when there are errors (hence
the elimination of the odd "hasError()"), but will come up more often
when we're deriving information from a combination of constraints.
This was previously handled very late, by the type checker, which led
to weird ordering dependencies and meant that we could end up with
well-formed code where the GSB was left with unresolved types. We want
such states to never exist, so make sure we can resolve everything in
the GSB.
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.
