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
Spurious unchecked warning #6275
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6275?orig=1 |
@retronym said: println(a: Seq[Int]) In the future, could you please first check on the [scala-language] mailing list before lodging tickets for things that are not clear bugs. |
Sriram Srinivasan (sriram.srinivasan) said (edited on Aug 24, 2012 6:11:11 AM UTC): The bigger issue, which affects my code everywhere is this: The variable |
@retronym said: |
@som-snytt said: The example is isInstanceOf, not asInstanceOf. For the case of asInstanceOf, there is no extra checkcast. Let's give intraprocedural analysis some respect. For the lack of a warning, #1558. So on that basis, I'll never asInstanceOf, because I'll never presume to tell the type system I know what I'm doing. Except maybe null.asInstanceOf. For the case of isInstanceOf, maybe the question is, should instanceof be optimized away. If you issue the instanceof, should you still warn? And if you must warn, is there a way to selectively turn off warnings? (Hopefully eventually?) |
@SethTisue said: |
@SethTisue said: |
@harrah said: I see the following spurious warning frequently, which drowns out useful unchecked warnings: sealed trait A[T]
final class B[T] extends A[T]
object ParsedAxis {
def x(a: A[Int]) =
a match {
case b: B[Int] => 3
}
}
In this case, the warning can be resolved by using a type variable: case b: B[i] => 3 but this is less useful when reading the code and isn't possible when
|
@harrah said: I'm not really working on 2.10 anymore, but if anyone wants it, this warning and other issues are handled here: https://github.com/paulp/scala/tree/topic/210-quieter-warnings |
gives the following warning under -checked:
Surely there should be no complaint about erasure in a purely local analysis. I'm telling it that it is a buffer of Int, and expect it to infer that it is a seq of Int.
The text was updated successfully, but these errors were encountered: