scala/scala — pull request #2680 by retronym (2013-06-24 12:34:04+00:00)
Title: SI-7603 Speculative fix for annotation binding error

Reports of:

error: trait Test is abstract; cannot be instantiated
11:09:50 [ant:scalac] @Test def testClientRequestNum = {
11:09:50 [ant:scalac] ^

Suggest that the deferred processing of a LazyAnnotationInfo is binding
the identifier `Test` to the wrong symbol. Inspection of the code shows
that the closure also defers capture of the (mutable) field
`Namer#typer.context`.

This commit captures the context eagerly, and adds logging to let us
know if that eagerly captured context ever differs from the its value
at the point when the annotation info is forced.

I spent a few hours trying to craft a test to back this up, but to no
avail. Here's what the log output will look like:

[log typer] The var `typer.context` in scala.tools.nsc.typechecker.Namers$NormalNamer@1f5ebb08 was mutated before the annotation new a() was forced.

current value = Context(C@Import unit= scope=123861466 errors=false, reportErrors=true, throwErrors=false)
original value = Context(C@Import unit= scope=123861466 errors=false, reportErrors=true, throwErrors=false)

This confirms the hypothesis for the cause of SI-7603. If you see this message, please comment on that ticket.

Check out the ticket for a bit more context.

Note that we've seen this error once on `t294.scala`, which has been benched for a while for non-determinism. In addition, the customer who reported the problem might well have had the CPS plugin enabled, which might affect the order that annotations are forced.

Review by the "Namer Whisperer", @lrytz. Does this hypothesis hold water? How might I provoke the error?