[3.1] Fix source compatibility problems with conforming to multiple Collection axes at once. #7151
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
…inference.
The associated type inference is a bit unusual, since we want to be able to infer associated types from protocol extension implementations that themselves depend on the types being inferred a certain way, e.g.:
```
protocol Runcible { associatedtype Spoon; func runce(_: Spoon) }
extension Runcible where Spoon == Hat {
func runce(_ hat: Hat) {}
}
```
For this reason, we would collect potential witnesses from all possible extensions of the type without immediately checking the constraints on each extension. This could lead to an inconsistency where, when ranking potential witnesses, associated type inference would end up picking the "best" candidate as something that can't even be used by the type we're inferring the witness for, leading to incomprehensible behavior. The ranking criterion itself is also flawed, because `TC.compareDeclarations` is normally comparing candidates for the same well-typed function invocation, but during associated type inference we haven't even established the type system we're comparing candidates within. Witness candidates from extensions with mutually exclusive associated type constraints but otherwise more specific constraints would be unnecessarily dismissed as ambiguous because neither candidate's generic signature is a match for the other's.
Both problems can be mitigated by looking at only the constraints for protocol extensions that specifically constrain the `Self` type, since those conformances are always explicit in the source code and therefore independent of associated type inference. We can pre-filter witness candidates by rejecting candidates for which the conforming type doesn't match the extension's Self constraints. We can score multiple witness candidates by looking only at the relative constraints they put on `Self`, considering a witness from a context that more specifically constrains Self to be a better candidate; we should ignore the associated type constraints for this scoring because we don't even know if they apply given the solution we'll ultimately pick. There's probably a more systemic way to go about this, but targeted fixes for both of these problems, along with a following patch to the standard library, restores source compatibility for Collection conformers, fixing rdar://problem/30228957.
…ex>) for combinations of [Mutable][RangeReplaceable][Bidirectional|RandomAccess]Collection. These were overlooked, and somehow code that attempted to make a minimal collection conform to RangeReplaceableCollection and RandomAccessCollection managed to compile successfully in Swift 3.0, but in Swift 3.1…*something* changed to reject a type that conforms to both due to the lack of a suitable default slicing subscript implementation in the stdlib that provided all the requirements. Fill in these missing implementations, fixing rdar://problem/30228957.
|
@swift-ci Please test |
|
Build failed |
jckarter
changed the title
|
@swift-ci Please clean test OS X |
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.
Explanation: Improvements to the type checker and standard library in Swift 3.1 exposed the lack of default implementations for a
SubSequencetype and slicing operator when a type conformed to multiple axes ofCollectionsimultaneously (Mutablevs non,RangeReplaceablevs non, and/or forward,BidirectionalorRandomAccess). Providing those default implementations then exposed remaining deficiencies in our handling of potential witnesses for associated type inference. This patch fixes these issues by constraining the type checker to only filter and compare witnesses by the constraints they require of theSelftype, which are invariant of what associated types we end up inferring, and then filling in the missing default implementations in the standard library.Scope: Many users writing custom collection types report this as a compatibility regression from 3.0.
Issue: rdar://problem/30228957
Risk: Moderate; there is a nonzero chance of knock-on effects. However, not taking this patch means that a large class of useful programs that compiled in 3.0 won't compile in 3.1 without boilerplatey source changes that get incorrectly rejected in 3.0, making it impossible to get code working in both versions. (See realm/realm-swift#4586 (comment) for an example.)
Testing: Swift CI; realm-swift project