Skip to content

Pattern matching with an AnyVal scrutinee fails with unreachable case error #7783

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
milessabin opened this issue Dec 16, 2019 · 2 comments
Closed

Comments

@milessabin
Copy link
Contributor

Compiling this,

object Test {
  def foo(t: AnyVal): Unit = t match {
    case _: Int =>
  }
}

gives me the following unreachable case error rather than the non-exhaustivity warning I was hoping for,

-- Error: local/nulls.scala:3:9 ------------------------------------------------
3 |    case _: Int =>
  |         ^
  |this case is unreachable since class AnyVal and class Integer are unrelated
1 error found

Assuming this is a bug and that this should instead give us a warning about a non-exhaustive match, then does this make the introduction of Null as a subtype of AnyVal with -Yexplict-nulls in #7546 problematic? Presumably the extra case would make previously exhaustive matches over existing AnyVals non-exhaustive?

@odersky
Copy link
Contributor

odersky commented Dec 16, 2019

This was indeed a bug. But you still won't get exhaustivity warnings since AnyVal is not sealed (it can have user-defined value classes besides the primitive value classes as children).

odersky added a commit to dotty-staging/dotty that referenced this issue Dec 16, 2019
The previous check demanded that the package prefix of a file corresponds
one-to-one with the directory name. This makes it illegal to have classes
in nested package clauses inside a file, which seems unreasonable. We now
only require that the file path is a prefix of the package path.
@milessabin
Copy link
Contributor Author

But you still won't get exhaustivity warnings since AnyVal is not sealed (it can have user-defined value classes besides the primitive value classes as children).

Nevertheless, should we be concerned that code which previously matched AnyVal scrutinees now has to be concerned about null?

milessabin added a commit that referenced this issue Dec 16, 2019
Fix #7783: Widen AnyVal to Any when checking class relation
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

2 participants