The code was favoring overloads where *either* argument matched its
parameter type and where both parameter types were the same. This
is really overly broad and can result in bugs like the one here, where
we only attempt the
(Int, Int) -> Bool
overload of '!=' despite the fact that it means forcing an
optional. We should select the
<T>(T?, T?) -> Bool
overload instead, and inject the non-optional operand into an optional.
Making this require *both* arguments to match mostly disables this
optimization, though, since for somethin like "a"+"b"+"c" the second
add has a type variable and string literal as arugments.
So instead, we'll just disable this in cases where one argument is the
optional of the other, to ensure we never try forcing one side. This
also means we'll disable the optimization in cases where we would
inject one operand into an optional, but that's likely find as we
don't have long chains of expressions where that happens.
Fixes rdar://problem/37073401.
This decreases total testing time by over a minute on my old Mac Pro.
It probably has much less effect on systems with fewer cores, but shouldn't
be any worse there.
Swift SVN r22745