Never use a protocol's requirement signature as a generic signature #10711
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
…ment. Match what the type checker is doing.
When a requirement signature could not be used to construct the requirement sources in a conformance access path (due to recursive protocols), we rebuild the path based on knowledge of the protocol. Instead of using the requirement signature for this (which depends on a canonicalized generic signature that breaks our intended invariants w.r.t. unresolved nested types), use the protocol's generic signature instead. This requires one small adjustment at the root of the path, but is otherwise NFC. Eliminates the penultimate use of AlwaysPartial.
Rather than pretend that the requirement signature of a protocol is a full, well-formed generic signature that one can meaningfully query, treat it as a flat set of requirements. Nearly all clients already did this, but make it official. NFC
DougGregor
force-pushed
the
requirement-signature-improvements
branch
from
910c2cf to
8f9618b
Compare
|
@swift-ci please smoke test and merge |
The outside representation already went to a flat set of requirements; make the internal representation match so we aren't tempted to use the requirement signature as inputs to a generic signature.
DougGregor
force-pushed
the
requirement-signature-improvements
branch
from
8f9618b to
5bacc08
Compare
|
@swift-ci please smoke test and merge |
1 similar comment
|
@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.
The protocol's requirement signature is not suitable for use as a complete generic signature, because it (intentionally) omits the root
Self: MyProtocolrequirement that makes the set of requirements sensible. Stop using generic signatures for requirement signatures---it's just a flat set of requirements.The only nontrivial change here is to conformance access paths. When we didn't have a requirement signature to use when constructing a requirement source (i.e., due to recursive protocols), we need to recanonicalize the path based on the now-computed requirement signature. This was canonicalizing using the generic signature formed from the requirement signature; use the protocol's generic signature instead, with a slight adjustment at the root of the requirement source.
All of this to eliminate the penultimate use of
ArchetypeResolutionKind::AlwaysPartial.