Fix the common error of using underscores instead of dashes.
In the rebranch this is an error (lit got more picky), but it also makes sense to fix the tests in the main branch
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
Calculate and set the type relation in each result building logic which
knows the actual result type.
CodeCompletionResultBuilder couldn't know the actual result type. From
the declaration alone, it cannot know the correct result type because it
doesn't know how the declaration is used (e.g. calling? referencing by
compound name? curried?)
func foo() {}
let a: Int = #^HERE^#
Previously, we marked 'foo()' as 'NotRecommented' because 'Void' doesn't
have any member hence it cannot be 'Int'. But it wass confusing with
'deprecated'.
Now that we output 'typerelation' which is 'invalid' in this case. So clients
can deprioritize results, or even filter them out.
rdar://problem/57726512
The check was disabled because of a typo, but was also duplicating a
check two lines above anyway, so remove it.
Credit to David Ungar for spotting it!
There were 2 functions to output argument list. Consolidate them and
consistently use it from every call like production (i.e. function call,
constructor call, enum with associated values, subscript)
Before checking type relation between candidate types and expected
types. In normal compilation, this removal is done in CSGen. However,
since code-completion directly uses Constraint System, we have to
manually remove argument labels before checking convertibility.
We can remove argument labels unconditionally because function types as
as value cannot have argument labels. (i.e. `let f: (a: Int) -> Int` is
illegal). That means, expected types shouldn't have any argument labels.
This fixes regression revealed in 5e75b1ad3b
rdar://problem/41496748
This either became dead shortly after the removal of Swift 3
compatibility mode from the constraint solver, or even earlier.
Note that the code completion test change is actually correct
because (Any) -> () is not convertible to () -> () in the
language.
These are all tests that would otherwise fail if the expression type
checker support for Swift 3 is removed.
I've moved some of the code from deleted Migrator tests into new
Constraints tests that verify that we do not support the constructs.
The underlying type-check was correct, but I forgot to consider it in
the outer code, and embarassingly never tested this case.
rdar://problem/28435922
We strip the first input type on instance methods like,
struct S { func foo(T) -> U } // (S)->(T)->U
but we should not do that when it's actually a curried instance method,
such as S.foo.
If we're completing in a context that expects a function type, try to
match methods/functions as function references before trying them as
calls. This means that
func take(_: (Int)->()) {}
func foo(a: Int) {}
take(#^A^#) // completes foo(a:) instead of foo(a: {#value#})
Note: doesn't yet work with generic types.
rdar://problem/28435922
