mirror of
https://github.com/apple/swift.git
synced 2026-02-27 18:26:24 +01:00
7b729933f6
Still record overload choices for `makeIterator` and `next` when solving a `ForEachElement` constraint. This maintains compatibility with the previous behavior where we would solve these in the constraint system, since the choices can affect ranking if e.g Collection's default `makeIterator` is compared with a concrete `makeIterator` overload. This is a complete hack though and we ought to rip this out as soon as we can. rdar://168840696
36 lines
1.2 KiB
Swift
36 lines
1.2 KiB
Swift
// RUN: %target-typecheck-verify-swift -swift-version 6 -verify-additional-prefix swift6-
|
|
// RUN: %target-typecheck-verify-swift -swift-version 7 -verify-additional-prefix swift7-
|
|
|
|
// REQUIRES: swift7
|
|
|
|
struct WrapperSequence<Base: Collection>: Sequence {
|
|
struct Iterator: IteratorProtocol {
|
|
mutating func next() -> Base.Element? {}
|
|
}
|
|
func makeIterator() -> Iterator {}
|
|
}
|
|
struct WrapperCollection<Base: Collection> : Collection {
|
|
typealias Element = Base.Element
|
|
typealias Index = Base.Index
|
|
|
|
var startIndex: Index {}
|
|
var endIndex: Index {}
|
|
|
|
func index(after i: Index) -> Index {}
|
|
subscript(idx: Index) -> Element {}
|
|
}
|
|
|
|
extension Collection {
|
|
func foo() -> WrapperSequence<Self> {} // expected-swift7-note {{found this candidate}}
|
|
func foo() -> WrapperCollection<Self> {} // expected-swift7-note {{found this candidate}}
|
|
}
|
|
|
|
func foo(_ x: some Collection) {
|
|
// This should be ambiguous since WrapperSequence & WrapperCollection are
|
|
// unrelated types, but was previously unambiguous purely because Collection's
|
|
// default 'makeIterator' was considered "less specialized" than WrapperSequence's
|
|
// concrete implementation.
|
|
for _ in x.foo() {}
|
|
// expected-swift7-error@-1 {{ambiguous use of 'foo()'}}
|
|
}
|