These fail with -requirement-machine-protocol-signatures=verify because
the GSB produces incorrect output. Enable the requirement machine
unconditionally for these tests, bypassing verification.
A new file test/Generics/same_type_requirements_in_protocol.swift
contains reduced versions of all of the failures, with FileCheck
used to confirm the exact requirement signature output.
When computing the requirement signature of a protocol, eliminate requirement
sources that are self-derived by virtual of using a given requirement of
that protocol to prove that same constraint.
Nested-type-name-match constraints are odd because they are
effectively artifacts of the GenericSignatureBuilder's algorithm,
i.e., they occur when we have two PotentialArchetypes representing the
same type, and each of those PA's has a nested type based on the same
associated type. Because of this, nested-type-name-match constraints
have no useful requirement sources, so the normal means of detecting
self-derived constraints doesn't suffice, and we end up with
self-derived nested-type-name-match constraints eliminating the
constraints they depend on, causing spurious "redundant same-type
constraint" diagnostics and minimized generic signatures that drop
important requirements.
Handle nested-type-name-match constraints by first keeping them out of
the connected-components algorithm used to compute same-type
constraints within an equivalence class. Then, detect self-derived
nested-type-name-match constraints by determining whether any of the
ancestor potential archetypes are in the same equivalence class... and
redundant with the edge that makes the ancestor potential archetypes
equivalent. Remove such self-derived edges, and treat all other
nested-type-name-match edges as derived, providing a minimized
signature.
Fixes SR-5841, SR-5601, and SR-5610
Detect requirement sources that are internally self-derived for
(e.g.) handling of requirement sources for same-type constraints and
superclass constraints. This eliminates some incorrect warnings about
redundant same-type constraints involving recursive protocols, which
(more importantly) were a symptom of incorrect generic signature
minimization.
Fixes SR-5473.
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.
When determining whether a conformance requirement source is
self-derived, ignore the top-level "Self: P" requirement in a
requirement signature.
Fixes SR-5485 / rdar://problem/33360699.
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.
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.
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.
Introduce `-enable-recursive-constraints` to disable the error about
direct recursion within a protocol definition. The implementation of
recursive protocol constraints is incomplete, but might be useful for
experimentation.
