Spurious pattern match exhaustivity warning involving higher-kinded types and variance

[TimWSpence]

Minimized code

sealed abstract class Resource[+F[_], +A] {
  import Resource.{Allocate, Bind, Suspend}

  def loop[G[x] >: F[x], B](current: Resource[G, Any]): G[B] =
    current match {
      case Allocate(_) => ???
      case Bind(_, _) => ???
      case Suspend(_) => ???
    }
}

object Resource {

  final case class Allocate[F[_], A](resource: F[A])
      extends Resource[F, A]

  final case class Bind[F[_], S, +A](source: Resource[F, S], fs: S => Resource[F, A])
      extends Resource[F, A]

  final case class Suspend[F[_], A](resource: F[Resource[F, A]]) extends Resource[F, A]

}

Output

dotc -explain dev/cats-effect/core/shared/src/main/scala/cats/effect/Resource.scala
-- [E029] Pattern Match Exhaustivity Warning: dev/cats-effect/core/shared/src/main/scala/cats/effect/Resource.scala:21:4
21 |    current match {
   |    ^^^^^^^
   |match may not be exhaustive.
   |
   |It would fail on pattern case: Resource.Allocate(_), Resource.Suspend(_)

Explanation
===========
There are several ways to make the match exhaustive:
 - Add missing cases as shown in the warning
 - If an extractor always return Some(...), write Some[X] for its return type
 - Add a case _ => ... at the end to match all remaining cases

Expectation

The above pattern match should be exhaustive

[liufengyun]

As a quick workaround, you can make F invariant in the class Resource:

sealed abstract class Resource[F[_], +A] {
  import Resource.{Allocate, Bind, Suspend}

  def loop[G[x] >: F[x], B](current: Resource[G, Any]): G[B] =
    current match {
      case Allocate(_) => ???
      case Bind(_, _) => ???
      case Suspend(_) => ???
    }
}

object Resource {

  final case class Allocate[F[_], A](resource: F[A])
      extends Resource[F, A]

  final case class Bind[F[_], S, +A](source: Resource[F, S], fs: S => Resource[F, A])
      extends Resource[F, A]

  final case class Suspend[F[_], A](resource: F[Resource[F, A]]) extends Resource[F, A]
}

[TimWSpence]

Thanks @liufengyun! Unfortunately we're sort of committed to covariance in F for user convenience and also committed to not forcing F to be covariant itself. You can see a discussion of this here: https://gitter.im/lampepfl/dotty?at=5f3d25b08b8d4f633e003717