diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2015-01-15 11:33:54 +1000 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2015-01-15 15:36:02 +1000 |
commit | 70ed23d58f9dd2d198250d2a889b60c88e39f59a (patch) | |
tree | 05865d9fe680629642f94fcf855d39ad56a41f6a /.gitattributes | |
parent | 05612399f78f34cb01fb31070eacf4a51b489dfb (diff) | |
download | scala-70ed23d58f9dd2d198250d2a889b60c88e39f59a.tar.gz scala-70ed23d58f9dd2d198250d2a889b60c88e39f59a.tar.bz2 scala-70ed23d58f9dd2d198250d2a889b60c88e39f59a.zip |
SI-9089 Another REPL/FSC + specialization bug fix
The enclosed test case stopped working in 2.11.5 on the back of
https://github.com/scala/scala/pull/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] https://github.com/scala/scala/pull/4040#commitcomment-8531516
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions