Imported From: https://issues.scala-lang.org/browse/SI-9232?orig=1
Reporter: Guillaume Martres (Smarter)
Affected Versions: 2.11.6
See #5365

Guillaume Martres (Smarter) said:
I did not mention it explicitely but replacing transformTree with:

  def transformTree(tree: Tree): Any = tree match {
    case Node1(_) => ???
  }

Also produces the warnings you'd expect:

test2.scala:14: warning: match may not be exhaustive.
It would fail on the following input: Node2()
  def transformTree(tree: Tree): Any = tree match {
                                       ^
one warning found

Which is why I'm saying that having unapplySeq without unapply somehow silences even unrelated exhaustivity warnings

@retronym said:
Extractor patterns within a pattern match typically disable analysis of exhaustivity and reachability. There is a special case for unapply methods that are irrefutable, that is, they statically return Some[T] rather than just Option[T]. Such patterns are considered to always match for the purposes of analysis.

Guards similarly hamper analysis:

object Test {
  def noWarningHere(x: Option[Any]): Any = x match {
    case Some(1) if "".isEmpty => ???
  }
}

Guillaume Martres (Smarter) said:

Extractor patterns within a pattern match typically disable analysis of exhaustivity and reachability.

Oh, I knew that this happened with guard but not with extractors. I think that two things need to be done at least:

• Have a warning (even an optional one) when the exhaustivity/reachability analysis is disabled.
• Try to do "best effort" analysis, e.g. in your example, replace case Some(1) if "".isEmpty by case Some(1) to do a partial analysis, or in my example replace case Node1(Foo(1)) by case Node1(_), this would already improve things a lot.

The warning is especially important because a type system is much more useful when it is reliable, it's hard to rely on the exhaustiveness checker because it's so easy to accidentally disable it.

Richard Bradley (richard.bradley) said:

Guards similarly hamper analysis:
...
[we should] have a warning (even an optional one) when the exhaustivity/reachability analysis is disabled.
it's hard to rely on the exhaustiveness checker because it's so easy to accidentally disable it.

I agree.
See also #5365 re guards disabling exhaustivity analysis. I don't see why they need to.