Enforce that we only see substituted requirements in checkRequirements() #70968
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
slavapestov
requested review from
a team,
AnthonyLatsis,
ahoppen,
bnbarham,
hamishknight,
hborla,
kavon,
rintaro and
xedin
as code owners
slavapestov
removed request for
a team,
AnthonyLatsis,
ahoppen,
bnbarham,
hamishknight,
hborla,
kavon,
rintaro and
xedin
…ntext::getProtocol()
…ownProtocolKind() checks
We don't support local types in generic context yet, but this avoids an assertion concerning type parameters.
slavapestov
force-pushed
the
check-requirement-invariant
branch
2 times, most recently
from
49821aa to
6f3bde5
Compare
- Pass around NominalTypeDecl instead of Type in a few places - Map type parameters to archetypes early instead of passing around a generic signature
… ErrorTypes to avoid triggering asserts
slavapestov
force-pushed
the
check-requirement-invariant
branch
from
6f3bde5 to
6fd1602
Compare
slavapestov
changed the title
slavapestov
force-pushed
the
check-requirement-invariant
branch
from
6fd1602 to
6adab3c
Compare
Contributor
Author
|
@swift-ci Please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #70937 and #70951.
To check if a substitution map satisfies a generic signature (for example, when resolving a generic type representation, or checking a conditional conformance) we apply a substitution map to each requirement to get a substituted requirement, then check if the substituted requirement is satisfied.
A substituted requirement is a statement about concrete types, so if a substituted requirement still contains type parameters we cannot answer questions about it, because we don't have a generic signature. For example, if
Tis a type parameter,[Array<T>: Equatable]cannot be answered one way or another, because we don't know ifT: Equatable.Clients should only check requirements against a substitution map whose replacement types are fully concrete, or contain archetypes. If
Tis an archetype, then[Array<T>: Equatable]can be decided by checking ifTconforms toEquatable.Formerly, checkRequirements() would silently return false if any requirements contained type parameters. Now, it asserts.
Note that most of the diff is a separate commit splitting off ConformanceLookup.cpp from Module.cpp.