When ranking overloads, always match up final closure parameters.

[jrose-apple]

There are a lot of other things that overload ranking does not take into account, and I intend to file a more general bug about that, but this should resolve some of the most egregious ambiguities with Swift 3's import rules (SE-0005, particularly "omit needless words" and adding default arguments).

Finishes rdar://problem/25607552. Depends on #4777 (well, not strictly, but that's how I structured the patch for now). 2eba353 is the thing to review here.

[jrose-apple]

@DougGregor, @rudkx, this is a bit more interesting than a diagnostic change. This certainly allows programs that were previously ambiguous to compile, but can you think of any cases where it would change the meaning of existing programs, or take something that was previously accepted and make it an error (through ambiguity or something else)?

@swift-ci Please test

[rudkx]

@jrose-apple I don't have an example in hand, but yes I think it might be possible to construct an example where after this change we would now consider something ambiguous where we wouldn't have previously.

Consider something like x.foo(a).bar{ $0 }.

We might have previously considered this unambiguous if there were two foo() that would both be acceptable but one was considered more specialized, and two bar() that would both be acceptable (each only acceptable with a particular foo()), but we considered neither to be more specialized. If we now consider the bar() that works with the less specialized foo() to be more specialized, we would have two working solutions, but they would end up with the same rank and be considered an ambiguity. This is what is happening with prefix() and map() today.

[jrose-apple]

Drat. That sounds like this shouldn't go into a 3.0 point release then, and may need to be behind a version check when it does go in. I'll see if I can come up with a concrete case to add to the test suite.

[jrose-apple]

I'm having a very hard time writing such a test case in practice, which might mean we'll be able to put this into 3.1. Any ideas how I could trigger this behavior?

// This example is accepted both with and without this patch.
class Ambiguity {
  func ambiguous(x: Int = 0, _: () -> Void) {}
}
class SubAmbiguity: Ambiguity {
  func ambiguous(_: () -> Void) {}
}

func orderedOverloads(_: Any) -> SubAmbiguity { return SubAmbiguity() }
func orderedOverloads(_: Int) -> Ambiguity { return Ambiguity() }

func testOrderedOverloads() {
  orderedOverloads(0).ambiguous {}
}

[jrose-apple]

@swift-ci Please test

[jrose-apple]

Revived and limited to Swift 4 mode!

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 27b4070
Test requested by - @jrose-apple

[jrose-apple]

@swift-ci Please test macOS

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 27b4070
Test requested by - @jrose-apple

[jrose-apple]

@swift-ci Please test macOS

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 27b4070
Test requested by - @jrose-apple

[jrose-apple]

@swift-ci Please test macOS

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 27b4070
Test requested by - @jrose-apple

[jrose-apple]

@swift-ci Please test macOS

[jrose-apple]

@swift-ci Please test source compatibility

[jrose-apple]

Wait, hang on, I don't need to run that since I made the change in Swift 4 only.

[DougGregor]

Looks good; I'm going to go ahead and merge