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

spurious "comparing non-null values .. will always return false" in pattern match #5932

Closed
scabug opened this issue Jun 15, 2012 · 7 comments
Closed
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jun 15, 2012

scala> class A
defined class A

scala> case object B extends A
defined module B

scala> (B: A with Product) match { case B => 0 }
<console>:10: warning: comparing non-null values of types B.type and A with Product using `==' will always yield false
              (B: A with Product) match { case B => 0 }
                                               ^
res2: Int = 0

scala> (B: A with Product) == (B: A)
res3: Boolean = true

scala> (B: A with Product) == (B: B.type)
res4: Boolean = true
@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 15, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5932?orig=1
Reporter: @retronym
Affected Versions: 2.10.0

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 19, 2012

@retronym said:
Without the pattern matcher:

class A

case object B extends A

object Test {
  val x1 = (B: A)

  println(x1 == B)
  println(B == x1)

  val x2 = (B: A with Product)

  println(x2 == B)
  println(B == x2) // spurious warning
}
@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 19, 2012

@retronym said:
Things go awry here:

args = List(Test#20.this.x2#9255)
underlyingClass(args.head.tpe) = Test#9258 // RefinementClassSymbol
receiver = object B#14 // ModuleClassSymbol
receiver isSubClass actual = false
@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 19, 2012

@adriaanm said:
Paul, assigning to you since it's not directly pattern matcher related (if I read Jason's comment correctly).

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 19, 2012

@retronym said:
Yep, pattern matcher isn't culpable.

I should have noted that receiver.tpe <:< actual.tpe = true, but things seem a bit roundabout, and I have a feeling this check is pretty subtle, so I'm not sure if that's right way to go.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 30, 2012

@scabug scabug closed this Jul 2, 2012
@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 8, 2012

@SethTisue said:
this bit me (well, toothlessly, since it's just a warning) in M4. delighted to find a fix already in place for M5. thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.