When comparing two functions for overload resolution, break apart the
parameter lists to compare individual parameters rather than comparing
the tuples. This allows us to prefer functions with fewer arguments to
ones with more, defaulted or variadic arguments. That preference was
already encoded in the constraint optimizer, which led to some strange
behavior where the preference was expressed for function calls but not
for calls to initializers. Fixes rdar://problem/24128153.
The standard library change tweaks the anachronistic, unavailable
"print" variants somewhat. The only behavior change here is a slight
regression for cases like:
print(a: 1, b: 2)
where we used to produce a diagnostic:
Please wrap your tuple argument in parentheses: 'print((...))'
but we now get:
argument labels '(a:, b:)' do not match any available overloads
However, this regression will happen at some point *anyway*, if
SE-0029 (or anything else that removes the implicit tuple splat
operation) goes through.
These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
OverloadedDeclRefExpr or OverloadedMemberRefExpr when there is no
contextual type information available. The problem is that CSRanking
will take a look at the various solutions formed by picking each member
of the set, and will arbitrarily rank them against each other based on
how specific the candidates are. The problem with this is that the
constraints on the candidates are being resolved by UnresolvedType, which
means that we end up accidentally pruning the overload set too early.
This can lead to incorrect diagnostics that *should* have been ambiguity
diagnostics, such as the example in TypeCoercion/overload_noncall.swift.
It also is causing me other grief as I'm trying to make the call analysis
diagnostics more specific and the lack of the proper candidates is
triggering badness.
The actual change to the testsuite here is minor, but not all good. It will
be re-won by later changes.
Swift SVN r31744
This allows us to remove the workaround generic overloads for "print" without sacrificing good diagnostics for its unavailable overloads. (rdar://problem/21499048, rdar://problem/21582758, rdar://problem/22126141)
Swift SVN r31169
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
