[SR-13415] Xcode 12b5: source incompatibility w/ generic overloads & trailing closures

[swift-ci]

Previous ID	SR-13415
Radar	rdar://problem/67451813
Original Reporter	rydermackay (JIRA User)
Type	Bug

Environment

Xcode 12b5 (12A8189h)

macOS 11.0b4 (20A5343i)

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug, TypeChecker
Assignee	None
Priority	Medium

md5: be271db21582958117b1f424ae61ac39

Issue Description:

I'm not sure if this a regression or a case of ill-formed code no longer being accepted.

Part of our codebase uses ReactiveSwift which defines types similar to the following:

struct Box<Value> {
    let value: Value
}

extension Box {
    // 1.
    func map<T>(_ f: @escaping (Value) -> T) -> Box<T> {
        return Box<T>(value: f(value))
    }
    
    // 2.
    func map<T>(_ value: T) -> Box<T> {
        return map { _ in value }
    }
    
    // 3.
    func map<T>(_ keyPath: KeyPath<Value, T>) -> Box<T> {
        return map { $0[keyPath: keyPath] }
    }
}

I just noticed that our own client code, which has "worked" for several releases, no longer compiles in Xcode 12b5. It looks more or less like this:

func test(input: Box<Void>) -> Box<String> {
    // Xcode 12b4: output is Box<String> (overload 1)
    // Xcode 12b5: output is Box<() -> String> (overload 2, but only when 3 exists!!)
    let output = input.map { "foo" }
    return output
}

The really weird thing is it compiles if I remove the seemingly unrelated overload 3 that takes a key path.

I wonder if this might be related to the recent forward scanning trailing closures changes?

[typesanitizer]

@swift-ci create

[LucianoPAlmeida]

I'm not sure the problem here has something to do with forward scanning closures, to me this is on overload selection where for some reason the solver is selecting overload 2 so to me is just a type inference issue. Given that introducing a new overload apparently unrelated causes the problem might the case where when there's only two overload solver can apply some favoring overload 1 where if we introducing a new one exposes the problem. We stumble on something similar before in #53977, where ambiguity was introduced after adding a third overload. In order to solve this we have to find out why solver is choosing overload 2.

This is indeed an issue, but as a workaround just to make it compile, you could explicitly add a contextual type in order to "tell" the compiler that you actually want overload 1 like:

func test(input: Box<Void>) -> Box<String> {
    let output: Box<String> = input.map { "foo" }
    return output
}

// or 
func test(input: Box<Void>) -> Box<String> {
    let output = input.map { "foo" } as Box<String>
    return output
}

// or 
func test(input: Box<Void>) -> Box<String> {
    return input.map { "foo" } 
}

In all those cases specifying the contextual type, the solver introduces a new constraint that makes the solver reject the overload 2 as no viable in this context, so only overload 1 is applicable.

cc @xedin

[swift-ci]

Comment by Ryder Mackay (JIRA)

Right, sorry I should've mentioned that too—we did work around the issue by adding explicit type annotations to the local variable just like your first example there. Thanks for looking into this!

[xedin]

I think this is a new behavior with seems to be associated with forward-scan for trailing closures which also landed very late in Xcode 12 development cycle. /cc @DougGregor

[AnthonyLatsis]

@DougGregor ping.

Revision update: Swift 5.9-dev (c1d5118)