-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Description
Description
A recent regression.
At a glace, based on -debug-constraints
output, it looks like the very first difference is - receiveCompletion: { _ in }
gets disconnected from the rest of the constraint system early because one of the dependent member types gets eagerly simplified down to a concrete type:
$T10 := (@escaping ((Subscribers.Completion<$T23.Failure>) -> Void), @escaping (($T23.Output) -> Void)) -> AnyCancellable
($T11, $T14) -> $T17 applicable fn $T10
$T23 := Publishers.CompactMap<Publishers.FlatMap<$T20, PassthroughSubject<Set<Value>, any Error>>, $T22>
$T11 arg conv ((Subscribers.Completion<any Error>) -> Void) 💥
The type of $T11
used to be ((Subscribers.Completion<Publishers.CompactMap<Publishers.FlatMap<$T20, PassthroughSubject<Set<Value>, any Error>>, $T22>.Failure>) -> Void)
which kept the closure connected to the rest of the constraint system.
This is the initial difference which causes solver to produce more solutions than before because order of binding selection changes.
Reproduction
import Combine
struct Value: Hashable {
}
protocol Item: Actor {
}
class Test {
var subject: PassthroughSubject<Set<Value>, Error>
init(subject: PassthroughSubject<Set<Value>, Error>) {
self.subject = subject
}
func test() {
subject
.flatMap { (values: Set<Value>) -> AnyPublisher<[any Item]?, Error> in
fatalError()
}
.compactMap { $0 }
.sink(
receiveCompletion: { _ in },
receiveValue: { _ in
Task { [weak self] in
}
})
}
}
Expected behavior
The expression should produce a single valid solution that uses non-throwing async overload of Task.init
.
Environment
Swift main branch @ 4afc2d4
Additional information
No response