Scala 2.10 build fails #10

kaptoxic opened this Issue Dec 15, 2012 · 4 comments


None yet

2 participants


This seems strange I am not sure what is causing the problem. It is definitely related to the Scala (presentation) compiler or to its invocation.

I made a separate branch for easier and controlled testing.
InSynth 2.10 build can be executed with command to execute only a single test class: "mvn install -P scala-ide-master-scala-trunk -DtestClassArg=ch.epfl.insynth.test.completion.InSynthCompletionTests".
This test is executed.
I think that the problem is here which invokes some compiler calls and then InSynth two times subsequently (it tests both snippet code styles).
In the first call InSynth returns all expected snippets. On the second one it does not.
The problem is definitely that InSynth does no see proper declarations the second time it is invoked (and thus cannot reconstruct expected solutions). The problem is not in the extraction part but it is that the compiler returns somewhat broken tree.
Note that, if one of these calls is commented then the test passes (this suggests that the second time, compiler indeed does not return a proper tree).

Do you have any ideas what can be the problem? I think its evident that it is not an issue with InSynth directly (also because it is working well for 2.9).

Perhaps it is because of these calls:

    project.withSourceFile(unit) { (src, compiler) =>
      val dummy = new Response[Unit]
      compiler.askReload(List(src), dummy)

      val tree = new Response[compiler.Tree]
      compiler.askType(src, true, tree)

The presentation compiler uses thread confinement as a concurrency management policy. So every call to the compiler API has to be wrapped in a compiler.askOption() call to ensure it runs on the presentation compiler's thread. See the documentation.

When you run your test, you create an InnerFinder which in turn collects solutions in InSynthWrapper.insynth.getSnippets. That call asks for the type of a symbol outside the presentation compiler thread, as can be seen in a stack trace of the log of Insynth's build.


I already know about the compiler thread and concurrency issues. It is strange that a race condition occurs since usually it breaks an assertion and does not report an error as you've shown (we fixed a lot of those)...

But the conclussion before was that InSynth works the first time it is invoked (every time) but fails afterwards... This is an issue you did not reproduce... (and you did not run the command as stated above, which runs only a single relevant test case)

Can you please make sure that you checkout the issue10 branch and that you run the command: "mvn install -P scala-ide-master-scala-trunk -DtestClassArg=ch.epfl.insynth.test.completion.InSynthCompletionTests"
Note that issue10 branch should have all compiler calls corrected and the argument to maven should execute only the relevant test as mentioned in the issue description.


Oh, but it does break an assertion : the assertion is hidden here.

I have indeed reproduced your issue in another build, I believe (logged there ). That being said, it seems the test is authentically spurious : I can get it to fail on the first invocation, once every 2-3 builds or so.

But if your calls to the compiler are not thread-safe, there is a good chance you may be looking for completions on an out of date version of your InteractiveCompilationUnit, and hence not returning the expected completion. Once in a while your threads reorder correctly, or the completion request is delayed enough, and the test passes. Solving the concurrency issue in your builds seems like a good path towards solving this problem.


I see. I've run this single test a couple of times and yes I agree, its spurious and sometimes it succeeds, sometimes fails (maybe a heisenbug as you've said 😄). But in either case I could not get those assertion fails as you've mentioned (I was looking at the output and scala-ide log).

By the way, I think that actually there are some exceptions thrown (due to concurrency), but they are all catched within the InSynth library and should not effect the whole synthesis.

Yes, I will need to take a look into this, since maybe those caught exceptions are actually preventing extraction of the right declarations.

@kaptoxic kaptoxic added a commit that referenced this issue Feb 23, 2013
@kaptoxic added dependency to Scala 2.10.1-RC1, fixed bugs due to PC thread access
(issue #10)
and changed some logging
@kaptoxic kaptoxic closed this Feb 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment