TODO:

• Test the strict version against the community build
• Approximate extractor patterns, too, rather than bailing out of exhaustivity.
• Check for new warnings in our build and address them
  • Compile library/reflect/compiler with -Xstrict-patmat-analysis: https://gist.github.com/453b894f164ce7e23665

s/exhautivity/exhaustivity ?

I just found another hole in our exhaustivity checking.

class Test {
  def foo {
    case class Foo(a: Any)
    val xs: List[Foo] = Nil
    xs match {
      case Foo(a) :: Nil =>
    }
  }
}

The constructor pattern Foo gets translated into a call to unapplySeq, rather than to a extractor of the case class product elements. This hampers exhaustivity checking (disabled it completely prior to this PR, and forces us to make an assumption even after this PR). It also means that the code is less efficient, and needlessly allocates a tuple.

This root cause of this was fixed recently as #4862 (which isn't merged yet to the 2.12.x branch).

I understand this still doesn't issue a warning if the type of scrut is not a sealed trait (unless I'm missing something). That is, code like this still compiles without a warning:

trait Z
final case class Q(i: Int) extends Z
def f(z: Z) = z match {
  case Q(_) =>
}

Would it be possible to get a warning in cases like this too? I realize, that this is even more strict than the -Xstrict-patmat-analysis in this PR, so maybe behind an -Xlint option?

Also, after playing a bit more with this code, the warnings for extractors seem to behave somewhat surprisingly. For example, code like this compiles without any warnings:

sealed trait T
final case class C(i: Int) extends T
final case class D(i: Int) extends T

object X {
  def unapply(t: T): Option[Int] = None
}

def g(t: T): Unit = t match {
  case X(_) =>
}

However, if I put in another case, thus increasing (or at least not decreasing) the exhaustiveness of the match, I get an (expected) warning:

def g(t: T): Unit = t match {
  case X(_) =>
  case C(_) =>
}

To be clear, the (to me) surprising thing is the absence of the warning in the first case. Is this behavior intentional?

Let's take another look at this after M5. Scheduling for RC1.

I don't have time to push this one forward right now, so I'm going to close the PR for now.

I’d like to pick this up, if it’s ok with @retronym.

My own opinions: it’d be nice to make “false” the default (@adriaanm – how likely is that?). Also, we should warn whenever the checker gives up (which I think would cover @durban’s X(_) case?) and I like the -Xlint idea for the unsealed trait case.

Great! I can be convinced of whatever strategy results in the best experience for the majority of Scala programmers.

We should at least let this be available behind a compiler flag. Without this people will avoid using guards so they can be sure of the exhaustive warning/compile error.