[AST] Introduce GenericSignature::getConformanceAccessPath(). #7956
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The stored dependent types in ProtocolRequirement elements within requirement sources were incorrect for requirements created from the requirement signature of another protocol, because we picked up the already-substituted subject type. Thread the optional substitution map through addRequirement(Requirement) as well, so we maintain the original spelling of the stored dependent type. This is a temporary fix; we should be able to recover the stored dependent types from the potential archetypes in the requirement source, so that we don't need to specify them explicitly at construction time.
The ad hoc substitution functions here were really odd; use SubstitutionMap directly, and pass it through to GenericSignatureBuilder::addRequirement().
Introduce an API that determines the "conformance access path" that
one would follow to find the conformance of a given type parameter
(e.g., T.Iterator.Element) to a given protocol (e.g., Equatable). A
conformance access path starts at one of the explicit requirements
of that generic signature and then proceeds through zero or more
protocol-supplied requirements. For example, given this function:
func f<C: Collection>(_: C) { }
The conformance access path for "C.Iterator: IteratorProtocol" is
(C, Collection) -> (Self, Sequence) -> (Self.Iterator, IteratorProtocol)
because one starts with the explicit requirement "C: Collection", goes
to the inherited protocol requirement (the "Self" in Collection
conforms to Sequence) and then a requirement on the associated type
(Self.Iterator in Sequence conforms to IteratorProtocol).
This is all scaffolding now; it's intended to be used by IRGen (to
find the witness tables it needs) and SubstitutionMap (to dig out
conformances during substitution).
|
@swift-ci please smoke test and merge |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce an API that determines the "conformance access path" that
one would follow to find the conformance of a given type parameter
(e.g.,
T.Iterator.Element) to a given protocol (e.g.,Equatable). Aconformance access path starts at one of the explicit requirements
of that generic signature and then proceeds through zero or more
protocol-supplied requirements. For example, given this function:
The conformance access path for
C.Iterator: IteratorProtocolisbecause one starts with the explicit requirement
C: Collection, goesto the inherited protocol requirement (the
SelfinCollectionconforms to
Sequence) and then a requirement on the associated type(
Self.IteratorinSequenceconforms toIteratorProtocol).This is all scaffolding now; it's intended to be used by IRGen (to
find the witness tables it needs) and
SubstitutionMap(to dig outconformances during substitution).