[CSBindings] Don't try to rank bindings based on number of defaults i…

[xedin]

…f they are literal

Number of defaults is a fallback condition if there are no other
differences, but pontential bindings which are literal should always
be ranked lower than anything else because there is a higher chance
that such bindings are wrong because their full set might not have
been resolved yet.

Resolves: rdar://problem/39616039

[xedin]

@swift-ci please test

[xedin]

@swift-ci please test source compatibility

[rudkx]

This seems problematic, as do the other tests that are looking at properties of x.

Consider what happens if you take the bindings from two type variables, T1 and T2, and pass them into this function twice, in different orders. You can end up with
T1 < T2 being false, and T2 < T1 being false, which implies that T1 == T2.

Based on your commit message, you're attempting to look for differences in type bindings other than the number of defaults, so this change does not seem consistent with that goal.

[xedin]

@rudkx There is a check for formBindingScore(x) < formBindingScore(y) already which does the actual comparison, this is just intended to make sure that type variable with default not no literal is going to be worth then a type variable without defaults but with literal bindings.

[xedin]

I'll make it so it always tests both sides to make this less ambiguous.

[xedin]

@rudkx suggested even better approach - we can just check formBindingScore in reverse to get the same effect here instead checking for subtype and literals, currently testing it out.

[xedin]

@swift-ci please test

[xedin]

@swift-ci please test source compatibility

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6fb5281afc5a7fc01cb00f50e4e029f05ba6690a

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 6fb5281afc5a7fc01cb00f50e4e029f05ba6690a

[xedin]

@swift-ci please test source compatibility

[xedin]

@swift-ci please test source compatibility

[xedin]

@swift-ci please test macOS platform

[xedin]

Both failed with EOFException, re-running...

[rudkx]

LGTM, thanks!