When a method is called with fewer than two parameter lists,
transform it into a fully-applied call by wrapping it in a
closure.
Eg,
Foo.bar => { self in { args... self.bar(args...) } }
foo.bar => { self in { args... self.bar(args...) } }(self)
super.bar => { args... in super.bar(args...) }
With this change, SILGen only ever sees fully-applied calls,
which will allow ripping out some code.
This new way of doing curry thunks fixes a long-standing bug
where unbound references to protocol methods did not work.
This is because such a reference must open the existential
*inside* the closure, after 'self' has been applied, whereas
the old SILGen implementation of curry thunks really wanted
the type of the method reference to match the opened type of
the method.
A follow-up cleanup will remove the SILGen curry thunk
implementation.
Fixes rdar://21289579 and https://bugs.swift.org/browse/SR-75.
Previously we would generate the following constraints here, where
'base', 'arg' and 'result' are concrete types, and $t is a type
variable:
- ValueMember(base, $t -> result)
- ArgumentTupleConversion(arg, $t)
Instead, we now generate these constraints:
- ValueMember(base, $method)
- ApplicableFunction(arg -> result, $method)
Recall that when the right hand side of an ApplicableFunction is
fixed, it simplifies down to an ArgumentTupleConversion and a
Bind. So the above formulation is equivalent, except that again,
we avoid forming a FunctionType where the entire input type is
a single type variable.
As with the UnresolvedDotExpr case, the old code set the
TVO_PreferSubtypeBinding flag on $t, so to preserve the old
ranking behavior, we generate an additional type variable and
constraint:
- FunctionInput($method, $arg)
This is just a temporary stop-gap until TVO_PreferSubtypeBinding
is removed.
Note that if the arguments to a constructor call are invalid, we
now fail the ApplicableFunction constraint and not a
ArgumentTupleConversion. This requires a minor change in CSDiag.
The whole concept of looking at the failed constraint is going
away hopefully, in favor of more precise TypeMatchResult and
Fix-based logic.
Previously we would generate the following constraint here, where
'base' was a concrete type and $arg and $result are type variables:
- ValueMember(base, $arg -> $result)
The problem is that we built a function type where the entire input
was a type variable, which would then bind to an argument list.
We could instead generate this constraint:
- ValueMember(base, $method)
That is not NFC though because we no longer have a type variable
bound to the argument list. Since $arg was created with
TVO_PreferSubtypeBinding, we would rank solutions by comparing
argument lists.
So we use the new FunctionInput constraint to extract the input
type of $method:
- ValueMember(base, $method)
- FunctionInput($method, $arg)
Once the ValueMember constraint is solved and $method has a fixed
type, $arg is bound to the function type's argument list, and
since it was created with TVO_PreferSubtypeBinding it participates
in ranking as before.
Amusingly enough, none of the tests in our suite exercised this
behavior, but the standard library would fail to build. So add a test.
This commit adds a new rule to `isDeclAsSpecializedAs` in order to favour a member on a concrete type over a protocol member. This rule is effectively an extension of the existing rule that prefers concrete type members over protocol extension members.
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
