-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Misleading warning "Unreachable case except for null" (and one more issue) #15661
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
Comments
I can't tell which is major or minor, but
is an int and a list of whatever it infers these days.
Here is a difference:
|
Yeah, only the null reachability lint is wrong. Even if scala> case class Composite[T](l: List[T], v: T)
Composite// defined case class Composite
scala> Composite[Any](List("foo", false), 1)
val res0: Composite[Any] = Composite(List(foo, false),1)
scala> res0.l.asInstanceOf[List[Int]].head + 1
java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')
at scala.runtime.BoxesRunTime.unboxToInt(BoxesRunTime.java:99)
... 35 elided |
I see, then I just have to be explicit in the type parameter, to prevent case Composite[Int](l, v) => Meaning this should not emit warning, right? case Composite[Int](l: List[Int], v) => |
No, there's nothing you can do. List is covariant, so anywhere it is, it could exist with a type argument that is a supertype of the precise type it was constructed with. Such as when it's a component of a |
The difference between I wonder if anyone has a meme handy of The Riddler from the old Batman tv show, whose signature was a giant |
Still a problem with Scala 3.2.0 |
I'm experiencing this in Scala 3.3.1 for a case where it wasn't occurring in 3.2.2. |
Is there a workaround for this in the meantime? |
Closes #15661 This is broken in 3.2.0-RC1, but fixed in main as well as 3.3.0-RC1.
Interesting, so was I correct saying that |
No:
|
Compiler version
Tested both 3.1.3 and 3.2.0-RC1
Minimized code
Output
Two bad warnings. First one is major, second one minor. Reporting both together, because I think they have the same root cause.
Unreachable case except for null (if this is intentional, consider writing case null => instead).
Strangely, If I follow the advice and specify
case null =>
I get a propermatch may not be exhaustive.
warning.the type test for List[Int] cannot be checked at runtime
Explanation:
List[Int]
does not need to be checked at runtime, because matching second parameter asInt
fixes the possible type of the list.Expectation
No warnings at all.
The text was updated successfully, but these errors were encountered: