fix #1484: position of while incorrect in debug

[liufengyun]

This commit fix #1484: position of while incorrect in debug. Also, it introduces the infrastructure for testing debuggability.

To add a new debuggability test, just put a scala file like the follows under tests/debug with debug annotations (see the comment in code for detail):

object Test {

  def main(args: Array[String]): Unit = {
    var a = 1 + 2
    a = a + 3
    a = 4 + 5 // [break] [step: while]

    while (a * 8 < 100) { // [step: a += 1]
      a += 1              // [step: while] [cont: print]
    }

    print(a) // [break] [cont]
  }
}

Review @felixmulder .

[liufengyun]

The debugging information is annotated as comments to the code in brackets:

val x = f(3) // [break] [next: line=5]
val y = 5

1. A jdb command must be wrapped in brackets, like [step]. All jdb commands can be used.
2. To check output of jdb for a command, use [cmd: expect].
3. If expect is wrapped in double quotes, regex is supported.
4. Break commands are collected and set globally.
5. Other commands will be send to jdb in the order they appear in the source file

Note: jdb uses line number starts from 1

[liufengyun]

As a side effect, this PR also tests bin/dotc and bin/dotr really work as expected.

[DarkDimius]

Very nice!

[felixmulder]

Very nice indeed!

LGTM, one question though - don't you want to run this on CI?

[liufengyun]

I think it would be good to run in CI.

[felixmulder]

So please add it :)

You do so in the drone.yml file. Please note that you also have to sign the new file using the command: drone sign lampepfl/dotty

[smarter]

You do so in the drone.yml file. Please note that you also have to sign the new file using the command: drone sign lampepfl/dotty

It would be much better if this could just be another JUnit test, we already have too many different commands to run all tests.

[liufengyun]

@felixmulder thanks for the tip, just added.

It would be much better if this could just be another JUnit test, we already have too many different commands to run all tests

The concern makes sense. However the debug test involves several processes and scripts, it would be a little awkward to do in JUnit. I can add a junit test to call the script when this becomes a problem.

[felixmulder]

@liufengyun - perhaps it would be possible to use jdb java interfaces directly instead of using expect?

It would be good to explore this before cementing on using the a script based solution, I agree with @smarter. If we can have this as unit tests, then that leads to less of a cognitive overhead when somebody looks at adding more of these tests in X day/weeks/years. :)

[smarter]

It's also necessary if we want the tests to run on Windows, we cannot rely on bash scripts then.

[smarter]

The "proper" way to do this would probably to use the JVM debugging APIs: https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/architecture.html I don't know how complicated they are to use.

[liufengyun]

I've checked JVM TI and JDI, both are possible alternative solutions. However, JVM TI requires writing C++ code, JDI involves technical details about the network connections and the debugging protocol.

From the point of view of maintenance, how much efforts we put in the implementation implies the cost it takes for a third person to maintain it. The JDB interface requires no knowledge from the API whatsoever, seems to be a much simpler approach to the problem.

WDYT ? @smarter @felixmulder

[smarter]

Another option would be to use http://scala-debugger.org/ though that would add a dependency on scala code to our test suite. For now, the simplest solution might be to disable the debugging tests when running on Windows.

[liufengyun]

Thanks @smarter , scala-debugger looks much more friendly and approachable.

[DarkDimius]

@liufengyun, note that as discussed during the meeting depending on scala artifacts isn't a good idea, as we'll need to compile&publish them before we test the compiler, ie you'll be building them with untested compiler.

[smarter]

as we'll need to compile&publish them before we test the compiler

As long as they are published with 2.11 and we support 2.11, we don't need to compile and publish them ourselves. If one day we stop supporting 2.11 artefacts then this is more problematic, but we can always publish scala-debugger with an already-tested and published version of dotty.

[DarkDimius]

The last clause is false if new version of dotty is binary incompatible with artifacts compiled by previous version, including stdlib. And I'm willing to bet that there would at least be several occasions when dotty will break binary compatibility.

…

On 9 February 2017 2:18:02 pm Guillaume Martres ***@***.***> wrote: > as we'll need to compile&publish them before we test the compiler As long as they are published with 2.11 and we support 2.11, we don't need to compile and publish them ourselves. If one day we stop supporting 2.11 artefacts then this is more problematic, but we can always publish scala-debugger with an already-tested and published version of dotty. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1951 (comment)

[liufengyun]

@smarter if the concern is about windows, then it's not a big issue, as the main thing used is expect scripts and JDB, both on windows as well. However, it depends on bin/dotc and bin/dotr, we have to have windows version of them first.

The driver script (link) is just a few lines, can easy be turned into powershell or the like.

[liufengyun]

@felixmulder : just checked the home on drone is /root. I think it is more consistent to have a symbolic link of ivy2 under /root/.ivy2 than changing $HOME to the place where ivy2 is located. As the latter may invalidate other assumptions on $HOME and may cause potential problems.

[felixmulder]

@liufengyun - sure, just remove the -ivy option and symlink before running sbt.

[felixmulder]

This PR needs to be rebased and the .drone.yml signed once more since it changed in #1957