So this is actually something that we need to fix in the Scala compiler and not the IDE project right?

If I remember correctly the issue is that the if we execute the following sequence

tree1 <- Parse the scala file
typTree <- type-check scala file
tree2 <- Parse the scala file

then tree1 != tree2 which is not what we want. Tree2 would be the typed-tree rather then the parsed tree.

I'll try to create a test-case later today :) Mostly because I miss coding.

We definitely need to fix this in the compiler side.

But, to we should also override the method `parseTree` in `ScalaPresentationCompiler` and copy/paste the implementation that fixes the issue to avoid any improper usage until we drop 2.9 support. Do you want to have a look at it? Or, I can do it today. It would be good to have the fix available in the upcoming IDE V2.1 release.

I would like to give it a go if you don't mind :) If it turns out I can't figure out how to fix it you can always take it over.

The issue is that a parse tree (i.e., an unattributed tree) should not contain any symbol (meaning that it should have no opportunity to trigger lazy typechecking of the tree).

As very well described in your write-up (https://github.com/scala-ide/docs/blob/master/src/sphinx/dev/architecture/presentation-compiler.rst):

_Another way to avoid the concurrency issue is to use a parsed tree rather than a typed one. *The parse tree has the interesting property that it can be safely accessed outside of the presentation compiler thread because it doesn't have any attributes, so there is nothing that can be lazily evaluated, hence no mutation and side effects*! This, however, is of course only possible if you don't actually need the information that is stored in the attributes. As mentioned you can get a parse tree by invoking the withParseTree method; at the time of writing this method is buggy and will sometimes return a typed tree, see the ticket for more information._

One side-effect of doing this is that the `ScalaIndexBuilder` may no longer work as expected. In fact, it is possible it's current implementation relies on the symbol being available.

Have a look at it, and get back here (or, even better, in the mailing list ;-)) if you have any question.

Sure, be my guest :-)

Anyway, this is not urgent, it is too risky to merge for Milestone 3. But it would be good to have it in right after we tag M3 (so that we can fix any realetd issue before the final release).

For reference the ticket is being discussed here https://groups.google.com/d/topic/scala-ide-dev/PP0Q3Kd5CUU/discussion

(In scala-ide:712e6bf5eb983a18aac03294c0656519d53ac634) Merge pull request #269 from mads379/parsetree-1001326

Fixes #1001326

Branch: master

(In scala-ide:fa5ab63b5a7f65d023f3d2a2bc08b5bc60cec8a1) Fixes #1001326

This commit fixes ticket #1001326. Solved the problem by
overriding 'parseTree(source: SourceFile)' in
ScalaPresentationCompiler with an implementation that just
parses the source every time without trying to memorize
anything. Added tests that checked that

1. You get a new parse tree every time you ask for one
2. A parse tree should never contain any symbols or types [1]
3. If you ask for a parse tree and then open the file it shouldn't
change the parse tree you originally asked for, i.e. property
2 still holds.

[1] There is an exception to this though. Some of the nodes that
the compiler generates will actually contain symbols. I've
chosen to just ignore these special cases for now.

Branch: master

Opened a ticket on the Scala issue tracker so I can send a pull request to the compiler as well https://issues.scala-lang.org/browse/SI-7026