Sema: Fix requirement/witness disambiguation for subclass existentials [4.0] #11242
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
When performing a lookup into a class C, we might find a member of C that witnesses a requirement in a protocol Q that C conforms to. In this case, AST name lookup returns both results. There are two further levels of fitering which can eliminate the ambiguity: - Sema name lookup maps requirements to witnesses if the base type of the lookup is a nominal type or a class-constrained archetype. Imported conformances don't have this mapping recorded, but there's another hack in this code path where if a requirement maps to itself inside a conformance, it is dropped from the results altogether. - If the duplicate results were not filtered out in Sema name lookup, there was another hack in CSRanking which would a witness higher than it's requirement when comparing solutions. This doesn't work for imported conformances, but usually name lookup filters out the duplicate results sooner, which also eliminates the exponential behavior from having multiple constraint system solutions. However, if we have a subclass existential C & P where C conforms to Q and we find a member of C that witnesses a requirement of Q, then (C & P) does not conform to Q. So if the conformance was imported, *both* of the above checks would fail to disambiguate the witness and requirement, and the member access would fail to type check. To make this work with imported conformances, teach Sema name lookup to extract the superclass from an existential before performing the conformance check. If the conformance check fails, it means we found the protocol member via the 'existential' part of the subclass existential (eg, in our case, a member of P), and we proceed as before. Fixes <rdar://problem/33291112>.
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
@DougGregor Does this look OK for 4.0? Also see the cleaner LookupResultBuilder on master... |
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.
Description: If an imported Objective-C class
Cconforms to an Objective-C protocolQwith a requirementfoo(), a member lookup offooon a value of typeC & P(wherePis some unrelated protocol) would be incorrectly reported as ambiguous. This fixes the disambiguation logic that is used for such lookups on a concrete typeCto also work for a subclass existentialC & P.Scope of the issue: This is a bug in a new feature, but in Swift 4.0 mode, we started importing Objective-C types like
C <P> *as subclass existentialsC & P, whereas previously we would import them as an existential typeP, so code examples that worked in Swift 3.2 mode can now fail to type check.Risk: Name lookup is a very tricky piece of code; hopefully the standard library, test suite and source compatibility test suite give us enough coverage here. I deliberately kept this patch for swift-4.0-branch as small as possible; there are other cleanups on master that hopefully make the logic here easier to follow and review.
Reviewed by: @DougGregor
Radar: rdar://problem/33291112.