Skip to content

Better handling of extractors in reachability check #2363

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

Closed
liufengyun opened this issue May 3, 2017 · 0 comments
Closed

Better handling of extractors in reachability check #2363

liufengyun opened this issue May 3, 2017 · 0 comments

Comments

@liufengyun
Copy link
Contributor

Dotty reports that in the following, one case is not reachable. Extractors should be better handled to avoid such annoying warnings.

sealed trait Expr
class IntExpr extends Expr
class BooleanExpr extends Expr

object IntExpr {
  def unapply(expr: Expr): Option[IntExpr] = ???
}

object BooleanExpr {
  def unapply(expr: Expr): Option[BooleanExpr] = ???
}


class Test {
  def foo(x: List[Expr]): Int = x match {
    case IntExpr(_) :: xs => 1
    case BooleanExpr(_) :: xs => 1                              //   <==   unreachable
    case Nil => 2
  }
}
@liufengyun liufengyun self-assigned this May 3, 2017
liufengyun added a commit to dotty-staging/dotty that referenced this issue May 12, 2017
1. Better handle exactors
2. Translate the pattern `List(pat1, pat2, c:_*)` to space semantically
3. Deal with extractors that return `Some[_]`

Previously we approximate extractor either to the extracted type or Empty,
which is too coarse, and it causes some false positives about unreachable case.
Introducing the concept extractor into the theory enables us to inspect the
patterns inside extractors and check more unreachable cases, which is not
supported by Scalac.

Scalac is silent with following code, but Dotty reports both unexhaustive and
unreachable warnings.

    sealed trait Node
    case class NodeA(i: Int) extends Node
    case class NodeB(b: Boolean) extends Node
    case class NodeC(s: String) extends Node

    object Node {
      def unapply(node: Node): Option[(Node, Node)] = ???
    }

    object Test {
      def foo(x: Node): Boolean = x match { // unexhaustive
        case Node(NodeA(_), NodeB(_)) => true
        case Node(NodeA(4), NodeB(false)) => true // unreachable code
      }
    }
liufengyun added a commit to dotty-staging/dotty that referenced this issue May 12, 2017
1. Better handle exactors
2. Translate the pattern `List(pat1, pat2, c:_*)` to space semantically
3. Deal with extractors that return `Some[_]`

Previously we approximate extractor either to the extracted type or Empty,
which is too coarse, and it causes some false positives about unreachable case.
Introducing the concept extractor into the theory enables us to inspect the
patterns inside extractors and check more unreachable cases, which is not
supported by Scalac.

Scalac is silent with following code, but Dotty reports both unexhaustive and
unreachable warnings.

    sealed trait Node
    case class NodeA(i: Int) extends Node
    case class NodeB(b: Boolean) extends Node
    case class NodeC(s: String) extends Node

    object Node {
      def unapply(node: Node): Option[(Node, Node)] = ???
    }

    object Test {
      def foo(x: Node): Boolean = x match { // unexhaustive
        case Node(NodeA(_), NodeB(_)) => true
        case Node(NodeA(4), NodeB(false)) => true // unreachable code
      }
    }
felixmulder added a commit that referenced this issue May 16, 2017
Fix #2363: better handle extractors in exhaustivity check
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant