- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Regression in specialization
Thu, 2011-10-13, 23:38
Hi,
There's regression in specialization logic caused by following commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd
This snippet illustrates the problem:
tsf-wpa-1-4252:scala-2.10.0.r25825-b20111013023509 grek$ ./bin/scalaWelcome to Scala version 2.10.0.r25825-b20111013020230 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_27). Type in expressions to have them evaluated.Type :help for more information.
scala> class Foo extends (Double => Double) { | def apply(x: Double) = x | }defined class Foo
scala> new Foojava.lang.NoSuchMethodError: scala.Function1$mcDD$sp$class.$init$(Lscala/Function1$mcDD$sp;)V at Foo.<init>(<console>:7) at .<init>(<console>:9) at .<clinit>(<console>) at .<init>(<console>:11) at .<clinit>(<console>) at $print(<console>) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:736) at scala.tools.nsc.interpreter.IMain$Request$$anonfun$15.apply(IMain.scala:976) at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43) at scala.tools.nsc.io.package$$anon$2.run(package.scala:19) at java.lang.Thread.run(Thread.java:680)
If you compare bytecode before d4a2e5ba and after that commit you'll notice, that $init$ method doesn't take specialized argument corresponding to trait's "this" as specialized one. I'll go ahead and revert the commit so better fix for the original problem can be worked on.
--
Grzegorz Kossakowski
There's regression in specialization logic caused by following commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd
This snippet illustrates the problem:
tsf-wpa-1-4252:scala-2.10.0.r25825-b20111013023509 grek$ ./bin/scalaWelcome to Scala version 2.10.0.r25825-b20111013020230 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_27). Type in expressions to have them evaluated.Type :help for more information.
scala> class Foo extends (Double => Double) { | def apply(x: Double) = x | }defined class Foo
scala> new Foojava.lang.NoSuchMethodError: scala.Function1$mcDD$sp$class.$init$(Lscala/Function1$mcDD$sp;)V at Foo.<init>(<console>:7) at .<init>(<console>:9) at .<clinit>(<console>) at .<init>(<console>:11) at .<clinit>(<console>) at $print(<console>) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:736) at scala.tools.nsc.interpreter.IMain$Request$$anonfun$15.apply(IMain.scala:976) at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43) at scala.tools.nsc.io.package$$anon$2.run(package.scala:19) at java.lang.Thread.run(Thread.java:680)
If you compare bytecode before d4a2e5ba and after that commit you'll notice, that $init$ method doesn't take specialized argument corresponding to trait's "this" as specialized one. I'll go ahead and revert the commit so better fix for the original problem can be worked on.
--
Grzegorz Kossakowski
Fri, 2011-10-14, 00:37
#2
Re: Regression in specialization
On 14 October 2011 01:25, Paul Phillips <paulp@improving.org> wrote:
I looked at your commit while chasing this bug and I was fairly sure it's not the guilty one. Other (more knowledgeable) people agreed. I was surprised when I finally reverted and rechecked generated bytecode.
I still don't know how to connect dots here.
--
Grzegorz Kossakowski
On Thu, Oct 13, 2011 at 3:37 PM, Grzegorz Kossakowski
<grzegorz.kossakowski@gmail.com> wrote:
> Hi,
> There's regression in specialization logic caused by following
> commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd
Interesting, interesting. I spent something like five hours on those
two lines, too. I am grateful you're in there catching these things
quickly.
I looked at your commit while chasing this bug and I was fairly sure it's not the guilty one. Other (more knowledgeable) people agreed. I was surprised when I finally reverted and rechecked generated bytecode.
I still don't know how to connect dots here.
--
Grzegorz Kossakowski
Fri, 2011-10-14, 05:47
#3
Re: Regression in specialization
On Thu, Oct 13, 2011 at 4:34 PM, Grzegorz Kossakowski
wrote:
> I still don't know how to connect dots here.
My trust dot-connecting tape carried the day. It came down to this:
scala> trait Foo1 { }
defined trait Foo1
scala> trait Foo2 { self => }
defined trait Foo2
scala> intp("Foo1").thisSym
res0: $r.intp.global.Symbol = trait Foo1
scala> intp("Foo2").thisSym
res1: $r.intp.global.Symbol = value self
And through whatever quirk of history, FunctionN is defined with an
unused self, whereas TupleN is not. Which is why it only impacted
FunctionN and AbstractFunctionN.
Seems pretty sketchy that thisSym might be a TypeSymbol or a
TermSymbol, and that a meaningless change at the language level can
actually flip it from one to the other. I think it would be less
surprising if thisSym were NoSymbol by default (rather than "this" as
it presently is.)
Fri, 2011-10-14, 07:47
#4
Re: Regression in specialization
On Fri, Oct 14, 2011 at 6:40 AM, Paul Phillips wrote:
> On Thu, Oct 13, 2011 at 4:34 PM, Grzegorz Kossakowski
> wrote:
>> I still don't know how to connect dots here.
>
> My trust dot-connecting tape carried the day. It came down to this:
>
> scala> trait Foo1 { }
> defined trait Foo1
>
> scala> trait Foo2 { self => }
> defined trait Foo2
>
> scala> intp("Foo1").thisSym
> res0: $r.intp.global.Symbol = trait Foo1
>
> scala> intp("Foo2").thisSym
> res1: $r.intp.global.Symbol = value self
>
> And through whatever quirk of history, FunctionN is defined with an
> unused self, whereas TupleN is not. Which is why it only impacted
> FunctionN and AbstractFunctionN.
>
> Seems pretty sketchy that thisSym might be a TypeSymbol or a
> TermSymbol, and that a meaningless change at the language level can
> actually flip it from one to the other. I think it would be less
> surprising if thisSym were NoSymbol by default (rather than "this" as
> it presently is.)
>
The reason `thisSym' is `this' is so that thisType can be this.thisSym.tpe.
It's a trick to shave some cycles off.
Cheers
On Thu, Oct 13, 2011 at 3:37 PM, Grzegorz Kossakowski
wrote:
> Hi,
> There's regression in specialization logic caused by following
> commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd
Interesting, interesting. I spent something like five hours on those
two lines, too. I am grateful you're in there catching these things
quickly.