scala-ide/scala-ide — pull request #849 by retronym (2014-10-30 08:24:21+00:00)
Title: Avoid spurious typer cycles / "no progress completing" errors

Scala IDE is currently experiencing spurious
cyclic and "no progress in completing" errors.

I attached a debugger to the IDE to try to catch it in the act.
I've recorded my findings and hypothesis in more detail in
https://www.assembla.com/spaces/scala-ide/tickets/1002325#

I managed to craft a test that demonstrates this. The test is
not included here, but in a branch in my scala repo.

https://github.com/retronym/scala/commit/2e75c7596558df4c9de2526246b5a65da018300b

In that, I have reproduced a scenario that matches
this hypothesis. In the first run, we stop shortly after running
the namer over a top level module. I've rigged up the test to then
create a new run, and then force the info of that module. This
triggers typechecking of that module's contents, which includes
a nested case class.

When entering a case class symbol, the namer needs to checks if there
is a user written companion object beside it. If not, a synthetic
companion must be created.

There is a tension in play in this lookup. If we are searching for
the companion of a member symbol from sources, we must not force the
owner's info prematurely, but rather be prepared to check the scope
in an enclosing `Context` to find the sibling symbol. Conversely,
if we are looking up the companion of a nested symbol sourced from
a class file, we must be careful to force the owner's info before
inspecting its members (SI-7264).

The mechanism to resolve this tension in `Namers#companionSymbolOf`
is predicated on whether or not the owner is compiled by the current
run.

This commit overrides `companionSymbolOf` changes the condition from
being run based to instead peeking at whether the owner has an source
`TypeCompleter` as its incomplete info.

I will roll this change into the presentation compiler proper
after we get some experience with the fix in the IDE.

Review by @dragos