3
votes

Current behavior:

  • Put a breakpoint on the case Twice(n) ... line.
  • On "step into" the control goes to x match { line
  • On "step into" the control goes to def TwiceTest = { line
  • On further "step into" the control goes to if (z % 2 == 0)... line.

Expected behavior:

  • Put a breakpoint on the case Twice(n) ... line.
  • On "step into" the control goes to if (z % 2 == 0)... line.

Code Snippet

object testobj extends App {
  def TwiceTest = {
    val x = Twice(21)
    x match {
      case Twice(n) => Console.println(n)
    } // prints 21
  }

  TwiceTest

}

object Twice {
  def apply(x: Int): Int = x * 2
  def unapply(z: Int): Option[Int] = {
    if (z % 2 == 0) Some(z / 2) else None
  }
}

The current behavior is irritating while debugging a scala program with lots of nested extractors. I tried this with the new Scala debugger as well as the Java debugger but with the same result.

Step Filtering also does not help in this case.

As a workaround, I am putting a breakpoint in the unapply method and running resume from the first breakpoint. Can someone please suggest me a cleaner method.

Edit 1 I am using Scala-IDE (latest nightly build. 2.1.0.nightly-2_09-201208250315-529cd70 )

Eclipse Version: Indigo Service Release 2 Build id: 20120216-1857

OS: Windows 7 ( 64 bit)

1
@om-nom-nom I am using Eclipse Indigo with the Scala IDE plugindips
I suggest to post this on scala-ide-userkiritsuku
@sschaef I have now posted the question on the Scala-ide-user group. But it is not visible yet in the group ...probably going through the moderation phase.dips
The list is not moderated. Google groups sometimes has problems in showing the send mails in the webinterface. Look again in some hours if it appears there.kiritsuku
@sschaef I reposted the question on the user group and got this pop up message. Your topic has been created and will appear after it has been approved.dips

1 Answers

0
votes

The line number information in the bytecode is wrong. It is not an issue with the IDE, but the Scala compiler. When pattern matching is compiled, synthetic code sometimes gets the wrong position information.

I assume you are using Scala 2.9.2. In the next version of Scala (2.10.0), there are significant improvements in the pattern matcher, so it would be good to give it a try.