FSC / REPL Bug Bonanza

Under resident compilation, we were getting multiple copies of static
forwarders created for mixed in methods. It seems like the bug was
fixed as a by-produce of scala#4040.

This commit adds a test to show this. I've confirmed that the test
fails appropriately with 2.11.4.

For future reference, before I figured out how to write the test
for this one (test/resident doesn't seem to let you run the code
after compiling it), I was using bash to test as follows:

    (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V  -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);

Under resident compilation, we were getting multiple copies of static
forwarders created for mixed in methods. It seems like the bug was
fixed as a by-produce of scala#4040.

This commit adds a test to show this. I've confirmed that the test
fails appropriately with 2.11.4.

For future reference, before I figured out how to write the test
for this one (test/resident doesn't seem to let you run the code
after compiling it), I was using bash to test as follows:

    (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V  -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);

Under resident compilation, we were getting multiple copies of static
forwarders created for mixed in methods. It seems like the bug was
fixed as a by-produce of scala#4040.

This commit adds a test to show this. I've confirmed that the test
fails appropriately with 2.11.4.

For future reference, before I figured out how to write the test
for this one (test/resident doesn't seem to let you run the code
after compiling it), I was using bash to test as follows:

    (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V  -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);

Under resident compilation, we were getting multiple copies of static
forwarders created for mixed in methods. It seems like the bug was
fixed as a by-product of scala#4040.

This commit adds a test to show this. I've confirmed that the test
fails appropriately with 2.11.4.

For future reference, before I figured out how to write the test
for this one (test/resident doesn't seem to let you run the code
after compiling it), I was using bash to test as follows:

    (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V  -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);

The enclosed test case stopped working in 2.11.5 on the back of
scala#4040.

The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.

In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.

This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.

I have found another spot that was directly manipulating the scope,
and removed the offending code.

The enclosed test case stopped working in 2.11.5 on the back of
scala#4040.

The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.

In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.

This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.

I have found another spot that was directly manipulating the scope,
and removed the offending code.

[1] scala#4040 (comment)

The enclosed test case stopped working in 2.11.5 on the back of
scala#4040.

The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.

In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.

This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.

I have found another spot that was directly manipulating the scope,
and removed the offending code.

[1] scala#4040 (comment)

The enclosed test case stopped working in 2.11.5 on the back of
scala#4040.

The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.

In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.

This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.

I have found another spot that was directly manipulating the scope,
and removed the offending code.

[1] scala#4040 (comment)

The enclosed test case stopped working in 2.11.5 on the back of
scala#4040.

The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.

In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.

This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.

I have found another spot that was directly manipulating the scope,
and removed the offending code.

[1] scala#4040 (comment)