Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: type inference involving higher-kinded types and upper-bounds #9676

Closed
rnd4222 opened this issue Aug 28, 2020 · 2 comments · Fixed by #9733
Closed

Regression: type inference involving higher-kinded types and upper-bounds #9676

rnd4222 opened this issue Aug 28, 2020 · 2 comments · Fixed by #9733

Comments

@rnd4222
Copy link

rnd4222 commented Aug 28, 2020

Minimized code

// compiles fine
object Main extends App {
  trait SubtypeOf[A[_], B[_]]
  implicit def instance[F[_], G[a] >: F[a]]: SubtypeOf[F, G] = new SubtypeOf[F, G] {}

  implicitly[SubtypeOf[List, Seq]]
}

// won't compile on dotty, but compiles fine on scala 2.13.3
object Main2 extends App {
  trait SubtypeOf[A[_], B[_]]
  implicit def instance[G[_], F[a] <: G[a]]: SubtypeOf[F, G] = new SubtypeOf[F, G] {}

  implicitly[SubtypeOf[List, Seq]]
}

Output

no implicit argument of type Main.SubtypeOf[List, Seq] was found for parameter ev of method implicitly in object DottyPredef.
I found:

    Main.instance[Nothing, Nothing]

But method instance in object Main does not match type Main.SubtypeOf[List, Seq].

Expectation

Implicit resolution works in both cases.

@smarter
Copy link
Member

smarter commented Aug 29, 2020

We don't even need implicit search to reproduce the problem:

object Test {
  trait SubtypeOf[A[_], B[_]]
  def instance[G[_], F[a] <: G[a]]: SubtypeOf[F, G] = new SubtypeOf[F, G] {}

  val x: SubtypeOf[List, Seq] = instance // error
}

@smarter smarter changed the title Regression: implicit search involving subtypes Regression: type inference involving higher-kinded types and upper-bounds Aug 29, 2020
@smarter
Copy link
Member

smarter commented Aug 31, 2020

It looks like our handling of constraints on higher-kinded type variable is incomplete, when we typecheck instance our constraint set looks like:

Constraint(
 uninstVars = G, F;
 constrained types = [G[_$3], F[a] <: G[a]] => SubtypeOf[F, G]
 bounds = 
     G[_$3]
     F[a] <: G[a]
 ordering = 
)

Notice that ordering is empty, compare with what we get in a method with simply-kinded type variables:

Constraint(
 uninstVars = G, F;
 constrained types = [G, F <: G] => SubtypeOf[F, G]
 bounds = 
     G
     F
 ordering = 
     F <: G
)

ordering is used to propagate constraints, the fact that we don't have it for hk types means that when we add an upper-bound constraint to G, we don't add the same constraint to F, so we might end up failing to find a valid solution to the type inference problem.

smarter added a commit to dotty-staging/dotty that referenced this issue Sep 5, 2020
If `?F <: [X] => ?G[X]`, then the ordering part of the constraint should
record `?F <: ?G`, otherwise constraints won't be propagated correctly.

It's not clear to me if we should make a similar change in `stripParams`
but note that doing so would require being a bit careful: since we use
the upper bound of a type variable to determine its kind, we can't just
replace it by `[X] => ?G[X]` by `AnyKind`.

Fixes scala#9676.
smarter added a commit to dotty-staging/dotty that referenced this issue Sep 18, 2020
If `?F <: [X] => ?G[X]`, then the ordering part of the constraint should
record `?F <: ?G`, otherwise constraints won't be propagated correctly.

It's not clear to me if we should make a similar change in `stripParams`
but note that doing so would require being a bit careful: since we use
the upper bound of a type variable to determine its kind, we can't just
replace it by `[X] => ?G[X]` by `AnyKind`.

Fixes scala#9676.
@Kordyjan Kordyjan added this to the 3.0.0 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants