Skip to content
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

Case class with varargs defeats exhaustiveness matching #8178

Closed
scabug opened this issue Jan 25, 2014 · 2 comments · Fixed by scala/scala#9140
Closed

Case class with varargs defeats exhaustiveness matching #8178

scabug opened this issue Jan 25, 2014 · 2 comments · Fixed by scala/scala#9140
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Jan 25, 2014

Including a case class with varargs in the constructor seems to prevent exhaustiveness checking from happening.

sealed trait Fails
case class VarArgs1(a: String*) extends Fails
case class FailsChild2(a: Seq[String]) extends Fails
object FailsTest {
  def matchOnVarArgsFirstFails(f: Fails) {
    f match {
      case VarArgs1(_) => ???
      // BUG: Without this line we should get a non-exhaustive match compiler error. 
      //case FailsChild2(_) => ???
    }
  }

  def matchOnSeqArgsFirstWorks(f: Fails) {
    f match {
      case FailsChild2(_) => ???
      // Without this line, the compiler reports a "match may not be exhaustive" error as expected.
      case VarArgs1(_) => ???
    }
  }
}

sealed trait Works
case class SeqArgs1(a: Seq[String]) extends Works
case class SeqArgs2(a: Seq[String]) extends Works
object WorksTest {
  def matcher(f: Works) {
    f match {
      case SeqArgs1(_) => ???
      // Without this line, the compiler reports a "match may not be exhaustive" error as expected.
      case SeqArgs2(_) => ???
    }
  }
}
@scabug
Copy link
Author

scabug commented Jan 25, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8178?orig=1
Reporter: @leifwickland
Affected Versions: 2.10.3, 2.11.0-M8

@scabug
Copy link
Author

scabug commented Mar 15, 2014

@retronym said:
This comes from:

val symbolicCases = approx.approximateMatch(cases, approx.onUnknown { tm =>
        approx.fullRewrite.applyOrElse[TreeMaker, Prop](tm, {
          case BodyTreeMaker(_, _) => True // irrelevant -- will be discarded by symbolCase later
          case _ => // debug.patmat("backing off due to "+ tm)
            backoff = true
            False
        })
      }) map caseWithoutBodyToProp

bailing out when encountering the ProductExtractorTreeMaker representing the null and length test.

P(x2,x2.a.!=(null).&&(x2.a.lengthCompare(1).==(0)),Substitution((p3,x2.a(0))))

@scabug scabug added the patmat label Apr 7, 2017
@scabug scabug added this to the Backlog milestone Apr 7, 2017
@adriaanm adriaanm removed their assignment Sep 28, 2018
@dwijnand dwijnand self-assigned this Sep 14, 2020
@dwijnand dwijnand modified the milestones: Backlog, 2.12.13 Sep 14, 2020
dwijnand added a commit to dwijnand/scala that referenced this issue Sep 14, 2020
dwijnand added a commit to dwijnand/scala that referenced this issue Sep 16, 2020
dwijnand added a commit to dwijnand/scala that referenced this issue Sep 24, 2020
@dwijnand dwijnand modified the milestones: 2.12.13, 2.13.4 Oct 20, 2020
@scala scala deleted a comment from scabug Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants