[ConstraintSolver] Forbid forming solutions with free generic type parameters

[xedin]

FreeTypeVariableBinding::GenericParameters mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.

This mode was used for code completion, which is now switched to use
FreeTypeVariableBinding::UnresolvedType instead.

[xedin]

@swift-ci please smoke test

[slavapestov]

This looks good, but what's with the operator+ showing up in completion results everywhere? Is it bogus?

[slavapestov]

@nkcsgexi Should take a look at this

[xedin]

@slavapestov I think this is correct actually because we allow unresolved types now which means if there is anything like +(Self, Self) -> Self it would be included, and there is a bunch of overloads like that.

[slavapestov]

Right, but when the left hand side is a tuple type, none of those overloads should apply, since there is a conformance constraint on Self.

[xedin]

True, I somehow only noticed that happening for objects, but I see that there is a tuple in there too, so don't know, maybe this exposed a bug somewhere in CompletionLookup. Any ideas, @nkcsgexi ?

[slavapestov]

Even for objects this operator should only show up if it conforms to the relevant protocols. It's worth investigating...

[rudkx]

The actual changes look good, but I agree we need to understand why the completion results change here.

[nkcsgexi]

@xedin I'm a little confused why does this change leads to showing + operator in the code completion list?

[nkcsgexi]

Looking into this a little bit, code completion calls typeCheckCompletionSequence for each potential operators to decide whether they should be included into the code completion list. It seems this line change caused a solution that used to be unviable for "+" now becomes viable, thus + is considered as a viable code completion item. Any idea why this line change is less strict than before?

[xedin]

Ok, the reason why + is returned in here is because + has multiple generic overloads and UnresolvedType is more permissive than GenericParameter, so what it's matching is -
Swift.(file).Strideable.+ : <Self where Self : Strideable> (Self.Type) -> (Self.Stride, Self) -> Self. I think I can tweak typeCheckCompletionSequence so if CCE is unresolved don't return it the solution.

[nkcsgexi]

Great, Thank you!

[xedin]

@slavapestov @rudkx @nkcsgexi Alright, all of the + overloads are gone from the results.

[xedin]

@swift-ci please smoke test

[xedin]

@nkcsgexi looks like it can't find x<< anymore, if I look at results I can see following list:

Results for filterText: x [
    {name:x}
    {name:x.}
    {name:x=}
    {name:x==}
    {name:x!=}
    {name:x<}
    {name:x>}
    {name:x<=}
    {name:x>=}
    {name:x+}
    {name:x-}
    {name:x*}
    {name:x/}
    {name:x%}
    {name:x+=}
    {name:x-=}
    {name:x*=}
    {name:x/=}
    {name:x%=}
    {name:x&<<}
    {name:x&>>}
    {name:x&<<=}
    {name:x&>>=}
    {name:x&}
    {name:x|}
    {name:x^}
    {name:x&=}
    {name:x|=}
    {name:x^=}
    {name:x...}
    {name:x...}
    {name:x..<}
    {name:x&*}
    {name:x&+}
    {name:x&-}
    {name:x~=}
]

It looks like that list has only operators with a single argument, do you think that is correct?

[nkcsgexi]

Since this test is on SourceKit side where it is not the main channel for us to test code completion correctness, updating the test accordingly and file a rdar to log such update makes sense.

[xedin]

Thanks, @nkcsgexi ! I've filed rdar://problem/32519796

[xedin]

@swift-ci please smoke test