[code-completion] Don't try to equate/convert GenericTypeParameterTypes when computing type relations of completion results #15411
Conversation
|
@swift-ci please test |
| if (!Ty->hasTypeParameter() && !ExpectedTy->hasTypeParameter()) { | ||
| if (Ty->isEqual(ExpectedTy)) | ||
| return CodeCompletionResult::ExpectedTypeRelation::Identical; | ||
| if (isConvertibleTo(Ty, ExpectedTy, *DC)) |
There was a problem hiding this comment.
If you look at isConvertibleTo it has some flags to turn type parameters or archetypes into type variables - this will produce a more accurate result. Might just be a matter of reusing the existing mechanism
There was a problem hiding this comment.
I tried changing isConvertibleTo to canPossiblyConvertTo (which passes openArchetypes=true) but does that make sense here since the two type parameters can have different generic contexts?
E.g. with the below snippet:
func foo<U, V>(_ _: U, _ _: V) where U: Sequence, V: Sequence {}
func bar<U, T>(lhs: T, rhs: U) where T: Collection {
_ = foo(lhs, #^COMPLETE^#
}
when adding type relations to the completion items for lhs we end up comparing Ty = T to ExpectedTy = V and isEqual and canPossiblyConvertTo both return true. For rhs we compare Ty = U to ExpectedTy = V where isEqual is false and canPossiblyConvertTo is true.
This could take much longer, let's not lie
…es computing type relations of completion results For call argument completion, if the expected type and completion result type are both GenericTypeParameterTypes, comparing them doesn't make sense we can't account for their different contexts at this point in the code, and hit assertions in the constraint solver if we try. For now, don't attempt to add a type relation for this case. Resolves rdar://problem/38153332.
nathawes
force-pushed
the
rdar38153332-code-completion-hits-unreachable-in-matchtypes
branch
from
7f169ff to
4a47133
Compare
For call argument completion, if the expected type and completion result type are
both
GenericTypeParameterTypes, comparing them doesn't make sense as we can't accountfor their different contexts at this point in the code, and hit assertions in the
constraint solver if we try.
For now, don't attempt to add a type relation for this case.
Resolves rdar://problem/38153332.