You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
wildApprox's job is to "approximate occurrences of parameter types and uninstantiated typevars by wildcard types". Unfortunately it's a little over-enthusiastic and also eliminates the type parameters bound by HKTypeLambdas used to represent kinds.
Implicit resolution is one of the main users of wildApprox and this bug showed up as a consequence of the fix for #6058. In the following,
the divergence checker reports divergence (via barF) when expanding Bar[B] in the process of expanding Bar[A]. It does this because even though Bar[A] and Bar[B] are not =:= (which should block divergence) currently wildApprox(Bar[A]) and wildApprox(Bar[B])are=:=.
This happens because the types A and B in Bar[A] and Bar[B] are wrapped in HKTypeLambdas at this point in typechecking, ie. these types are effectively represented as,
Bar[[T] =>A[T]]
Bar[[T] =>B[T]]
When wildApprox is applied to them they're transformed into,
Bar[[T] =>A[_]]
Bar[_ <: [_$1] =>Any]
respectively, which =:= then report as equal (this is also a bit fishy, but the wildApprox transformation is clearly wrong).
This can be fixed (PR incoming) by modifying wildApprox to leave alone TypeParamRefs corresponding to HKTypeLambdas which represent kinds.
The text was updated successfully, but these errors were encountered:
Replacing a higher-kinded bound by a wildcard changes its kind.
We need to keep the bound intact in this case but recursively
approximate its contents.
smarter
pushed a commit
to dotty-staging/dotty
that referenced
this issue
Apr 6, 2019
I'm not entirely sure why this fixes the issue but the previous behavior
seems dubious to me: what's the meaning of applying a WildcardType
argument to a type lambda ? By contrast, applying a TypeBounds has a
well-defined behavior (`appliedTo` will call `TypeApplication#Reducer` to
get rid of the type lambda).
smarter
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 6, 2019
I'm not entirely sure why this fixes the issue but the previous behavior
seems dubious to me: what's the meaning of applying a WildcardType
argument to a type lambda ? By contrast, applying a TypeBounds has a
well-defined behavior (`appliedTo` will call `TypeApplication#Reducer` to
get rid of the type lambda).
smarter
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 6, 2019
I'm not entirely sure why this fixes the issue but the previous behavior
seems dubious to me: what's the meaning of applying a WildcardType
argument to a type lambda ? By contrast, applying a TypeBounds has a
well-defined behavior (`appliedTo` will call `TypeApplication#Reducer` to
get rid of the type lambda).
wildApprox
's job is to "approximate occurrences of parameter types and uninstantiated typevars by wildcard types". Unfortunately it's a little over-enthusiastic and also eliminates the type parameters bound byHKTypeLambdas
used to represent kinds.Implicit resolution is one of the main users of
wildApprox
and this bug showed up as a consequence of the fix for #6058. In the following,the divergence checker reports divergence (via
barF
) when expandingBar[B]
in the process of expandingBar[A]
. It does this because even thoughBar[A]
andBar[B]
are not=:=
(which should block divergence) currentlywildApprox(Bar[A])
andwildApprox(Bar[B])
are=:=
.This happens because the types
A
andB
inBar[A]
andBar[B]
are wrapped inHKTypeLambdas
at this point in typechecking, ie. these types are effectively represented as,When
wildApprox
is applied to them they're transformed into,respectively, which
=:=
then report as equal (this is also a bit fishy, but thewildApprox
transformation is clearly wrong).This can be fixed (PR incoming) by modifying
wildApprox
to leave aloneTypeParamRefs
corresponding toHKTypeLambdas
which represent kinds.The text was updated successfully, but these errors were encountered: