More correctly fix SR-5485: we were retaining self-derived conformance
sources when we shouldn't, which led to spurious "redundant
conformance" diagnostics and (much worse) incorrect minimized generic
signatures. Now, when we detect a self-derived conformance source,
return the minimal source that will derive the same conformance... and
retain that one if it's new.
processDelayedRequirements() was putting reprocessed-but-still-unresolved
requirements directly into the global delayed-requirements queue,
which meant that they didn't benefit from the optimization of putting
delayed requirements into the appropriate equivalence class.
Revise the meaning of UnresolvedHandlingKind::ReturnUnresolved (and
change its name to GenerateUnresolved) to still generate the
unresolved constraint, but notify the caller that it remained
unresolved. That way, we can track what happens when reprocessing
requirements (the statistics are *really* useful), but we still get
the optimization from putting delayed requirements onto the
equivalence class that can resolve them.
With this change, type checking the standard library is now only 1%
slower with ``enable-recursive-constraints`.
When a requirement is delayed, we know the equivalence class that
would have to change to make the requirement potentially
resolvable. Record the delayed requirement on that equivalence class.
When an equivalence class is modified for any reason, move all of the
delayed requirements to the global delayed-requirements queue so
they'll be reprocessed. This cuts the number of
reprocessed-but-still-unresolved requirements in half when
type-checking the standard library, taking us from 4x slower to 3x
slower.
Replace the overly-general bumpGeneration() with a "modified()"
operation on EquivalenceClass, indicating that the given
EquivalenceClass has been modified in some way. There are no
modifications in the system that do not directly affect an equivalence
class.
When we fail to resolve a particular type to a potential archetype,
track which equivalence class would have to change for the resolution
of that type to succeed. For now, this is "just" more bookkeeping.
Whenever we need a complete, well-formed potential archetype,
reprocess any delayed requirements, so that we pick up additional
requirements on that potential archetype.
This relies on us tracking a generation count for the GSB instance as
a whole, which gets bumped each time we add some new requirement or
create a new potential archetype, and only actually reprocessing
delayed requirements when the generation count exceeds the point at
which we last processed delayed requirements.
This gets the most basic recursive protocol constraint working
end-to-end and doesn't seem to break things.
Inheritance of a protocol from JavaScriptCore's JSExport protocol is
used to indicate that the methods and properties of that protocol
should be exported to JavaScript. The actual check to determine
whether a protocol (directly) inherits JSExport is performed via the
Objective-C runtime. Note that the presence of JSExport in the
protocol hierarchy is not sufficient; the protocol must directly
inherit JSExport.
Swift warns about redundant conformance requirements and eliminates
them from the requirement signature (and, therefore, the Objective-C
metadata). This behavior is incorrect for JSExport, because the
conformance is actually needed for this API to work properly.
Recognize a protocol's inheritance JSExport specifically (by
name) when computing the requirement signature of the protocol. When
we find such a redundancy, suppress the "redundant conformance
constraint" diagnostic and add a new (hidden) attribute
@_restatedObjCConformance(proto). The attribute is used only by Objective-C
protocol metadata emission to ensure that we get the expected metadata
in the Objective-C runtime.
Fixes rdar://problem/32674145.
This reverts commit afbdbae9d9.
Commit ded45a6e1c more than triples the
type checking time when building Swift.o, so I am going to revert that ,
and it looks like this needs to be reverted as well if that commit is
reverted.
All of this is dead code now that we don't use
ArchetypeResolutionKind::AlwaysPartial and, therefore, cannot ever
produce an unresolved potential archetype.
PotentiallArchetype::getNestedType(Identifier...) was using
ArchetypeResolutionKind::AlwaysPartial, even though only one client
(the code that itself handles AlwaysPartial) needed it. Add an
ArchetypeResolutionKind parameter to pass through, updating clients
accordingly.
Eliminates 5 effective uses of AlwaysPartial. Only two left!
When a concrete requirement is invalid due to the concrete type
lacking a conformance to a particular, required protocol, don't emit
that incorrect requirement---it causes invalid states further down the
line.
Fixes SR-5014 / rdar://problem/32402482.
While here, fix a comment that Huon noticed trailed off into oblivion.
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.
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.
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.
A `GenericSignatureBuilder` only needs to be finalized when we need to
compute a generic signature from it or otherwise require diagnostics.
Canonical generic signature builders don’t need either of those, so unless we
are performing the expensive idempotency checking, only do the minimal work
to “process delayed requirements”.
This gives a 3x speedup in type-checking time for the “trivial” example
let x = [1, 2]
because we do a lot less work on deserialization of generic environments.
Part of rdar://problem/32116933.
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.
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.
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.
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().
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.
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.
Rather than true (an error occurred) or false (the constraint was
resolved), introduce ConstraintResult to better model what
happened. NFC for now, but the intent here is to report unresolved
constraints through this mechanism.
