We don't have a great collection of tests for the ranking that we do
in the constraint solver. This is a very simple beginning that I will
build on in further commits.
The primary aim here is to document the current state of how we're
selecting things, and make note of anything that doesn't seem like the
right long term choice so that we can begin to address the issues.
This is largely motivated at the moment by the changes I had to revert
for dealing with Optional and Any in ranking, which on both ranking
changes and scoring changes, the latter of which inadvertantly changed
other behavior about how we ultimately select a final solution in type
checking.
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
constraint solver produces multiple solutions. The criteria for "best"
are fairly simple: we compare the bindings for each type variable
bound in both solutions:
- If the binding in the first solution is a subtype of the binding
in the second solution, but not vice-versa, the first solution is
at least as good as the second
- If the type variable has a literal constraint on it, and the bound
type in the first solution matches the default literal type for
that literal kind, the first solution is as good as the second.
From there, we follow the obvious rules for picking a winner: if some
of the type variables in the first solution are as good as the same type
variables in the second solution, but none of the type variables are
worse, then the first solution is better.
We can now type-check "1 + 2.0". Take *that*, TypeCheckCoercion.cpp.
Swift SVN r2894
