Possible regression in overloads resolution for closures

[Eugene_Gubin]

Code:

public func foo<T>( _ expression: @autoclosure @escaping () throws -> T, file: String = #file, line: Int = #line, function: String = #function) -> T {
    try! expression()
}

public func foo<T>(_ file: String = #file, line: Int = #line, function: String = #function, expression: @escaping () throws -> T)  -> T {
    try! expression()
}

let value = foo { 42 }

print(value)

Output (5.4 toolchain for Windows, 5.3.2 in Xcode 12.4):

G:\Projects\OverloadDemo\Sources\OverloadDemo\main.swift:9:13: error: ambiguous use of 'foo'
let value = foo { 42 }
            ^
G:\Projects\OverloadDemo\Sources\OverloadDemo\main.swift:1:13: note: found this candidate
public func foo<T>( _ expression: @autoclosure @escaping () throws -> T, file: String = #file, line: Int = #line, function: String = #function) -> T {
            ^
G:\Projects\OverloadDemo\Sources\OverloadDemo\main.swift:5:13: note: found this candidate
public func foo<T>(_ file: String = #file, line: Int = #line, function: String = #function, expression: @escaping () throws -> T)  -> T {
            ^

It compiles with older toolchains (5.1). I think, it may be related to multiple trailing closures.

[xedin (Pavel Yaskevich)]

Looks like this has been fixed on main, the second overload should be preferred over the one with @autoclosure when argument is a closure.