Skip to content

Improve subtyping check for not yet eta-expanded higher kinded types #17139

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Apr 22, 2023
Merged

Improve subtyping check for not yet eta-expanded higher kinded types #17139

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion compiler/src/dotty/tools/dotc/core/TypeComparer.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -580,7 +580,7 @@ class TypeComparer(@constructorOnly initctx: Context) extends ConstraintHandling
val base = nonExprBaseType(tp1, cls2)
if (base.typeSymbol == cls2) return true
}
else if tp1.isLambdaSub && !tp1.isAnyKind then
else if tp1.typeParams.nonEmpty && !tp1.isAnyKind then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this, this could be quite a drastic change that needs more motivation. Can you push to staging, then I can try some things?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@odersky pushed.
The problem I'm trying to fix here is that when the compiler tries to compare two higher-kinded types like Foo1 and Foo2 in the test example, it returns false too early without trying to eta-expand the types. In the other cases from the linked issue, where everything compiles successfully, for some reason at least one of the compared types gets already eta-expanded at some earlier stage, which leads the compiler in the right direction to prove that the subtyping relation does occur.
To be more precise, the 2 alternative working workarounds are:

  • remove the theoretically redundant package prefix, changing
implicit val bar: Bar[pkg.Foo2]

into

implicit val bar: Bar[Foo2]
  • compile both files in a single compiler run (e.g. by renaming Test_2.scala to Test_1.scala when compiling with vulpix)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@odersky have you managed to experiment with these changes? If there any chance to push this forward?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does avoid the fourthTry logic for the cases where tp1 is a generic class without type parameters. But I checked that this logic does not do anything in this case, so I think the change is OK.

return recur(tp1, EtaExpansion(tp2))
fourthTry
}
Expand Down
14 changes: 14 additions & 0 deletions tests/pos/i16183/Lib_1.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
package pkg

trait Foo1[A]
trait Foo2[A] extends Foo1[A]

trait Bar[F[_]]
object Bar {
implicit val bar: Bar[pkg.Foo2] = ???
}

trait Qux
object Qux {
implicit def qux[F[_]](implicit bar: Bar[F]): F[Qux] = ???
}
6 changes: 6 additions & 0 deletions tests/pos/i16183/Test_2.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
import pkg._

object Test {
implicitly[Foo2[Qux]]
implicitly[Foo1[Qux]]
}