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

singleton type pattern should use `eq`, not `==` for test #4577

Closed
scabug opened this issue May 13, 2011 · 12 comments
Closed

singleton type pattern should use `eq`, not `==` for test #4577

scabug opened this issue May 13, 2011 · 12 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented May 13, 2011

GI intend to conquer the pattern matcher this time. Have to do some ticketizing.

The following test case reveals multiple significant issues with equality, including calling equals when it's supposed to be using reference equality, and considering a stable identifier foo to be unreachable on the basis that _: foo.type had not matched. (It can actually learn nothing, because the one should be reference equality and the other should be a call to equals.)

object Test {
  val bippy    = new Symbol("bippy")
  val imposter = new Symbol("bippy")
  val notBippy = new Symbol("not-bippy")
  val syms = List(bippy, imposter, notBippy)

  class Symbol(val name: String) {
    override def equals(other: Any) = other match {
      case x: Symbol  => name == x.name
      case _          => false
    }
    override def toString = name
  }

  def f(s: Symbol) = s match {
    case _: bippy.type  => true
    case _              => false
  }
  def g(s: Symbol) = s match {
    case _: bippy.type => 1
    case `bippy`       => 2
    case _             => 3
  }
  
  def main(args: Array[String]): Unit = {
    // should be: true false false
    syms map f foreach println
    // should be: 1 2 3
    syms map g foreach println
  }
}
@scabug
Copy link
Author

@scabug scabug commented May 13, 2011

@scabug
Copy link
Author

@scabug scabug commented Feb 8, 2013

@paulp said:
Update Feb 2013: all bugs successfully made the transition from oldpatmat to newpatmat. Good job, bugs.

@scabug
Copy link
Author

@scabug scabug commented Apr 24, 2013

@paulp said:
Just for fun I'm marking this a blocker; it shouldn't be that hard to fix, and with the pattern matcher receiving so much love it seems wrong not to fix something so fundamental.

@scabug
Copy link
Author

@scabug scabug commented Apr 24, 2013

@paulp said:
Of course, with "blocker" the default priority in JIRA, I may have unwittingly consigned it to oblivion.

@scabug
Copy link
Author

@scabug scabug commented Apr 24, 2013

@paulp said:
In the interests of making the blockers a little blockier, I bulk-edited most of the "Blockers" down to "Major".

https://issues.scala-lang.org/secure/IssueNavigator.jspa?mode=hide&requestId=12202

@scabug
Copy link
Author

@scabug scabug commented Oct 15, 2013

@gkossakowski said:
Unassigning and rescheduling to M7 as previous deadline was missed.

@scabug
Copy link
Author

@scabug scabug commented Jan 14, 2014

@adriaanm said:
rock, meet hard place... I'm not sure we can fix this in 2.11

@scabug
Copy link
Author

@scabug scabug commented Jan 14, 2014

@paulp said:
I believe rock and hard place are already well acquainted.

@scabug
Copy link
Author

@scabug scabug commented Feb 19, 2014

@scabug scabug closed this Feb 21, 2014
@scabug
Copy link
Author

@scabug scabug commented Mar 6, 2014

Stephen Compall (s11001001) said:
Yes. Thank you @adriaanm!

@scabug
Copy link
Author

@scabug scabug commented Mar 6, 2014

@adriaanm said:
Pleasure.

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.