This page is no longer maintained — Please continue to the home page at www.scala-lang.org

inlining vs. inferring. inferring wins.

No replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

Trying to figure out why all the tests pass fine for me but not
for jenkins (finding no reason, I can only assume wrong jenkins
configuration either not cleaning properly or actually running the tests
against old classfiles, neither of which is terribly encouraging) I
lucked into discovering that range inlining has been broken for a while.
The "it's a trap!" reason is the following line in trait
CustomParallelizable.

protected override def parCombiner = throw new
UnsupportedOperationException("")

"But extempore, how could that line in CustomParallelizable be
preventing Range.foreach from being inlined? That's so impossible!"

When you override a method and let the type be inferred it will do its
thing, and its thing is to infer the most specific type. That means that
through the magic of covariant return types, the new signature for
parCombiner in classes mixing in that trait is

def parCombiner: Nothing

Then when the icode loader goes to load Range (which mixes in
CustomParallelizable) it gets confused and abandons ship.

I find the inference of Nothing in this situation particularly hard to
defend because there is no way to say what I would probably want to say,
which is

override def parCombiner: typeOf[super.parCombiner] = throw ...

In the following, how does one define foo in class B such that:

1) class A's foo definitions can be swapped without modifying B
2) class C compiles

Can you? I can't. But I should be able to.

class A {
def foo = new A
// def foo = new B
}

class B extends A {
override def foo = sys.error("")
}

class C extends B {
override def foo = new C
}

Another thing. There is a second seems-like-it-should-be-a-bug issue in
the same line of code: if you try to leave the line as-is and return the
same type as the superclass, compilation fails because of a variance
error. The method has to be protected[this] to avoid variance
restrictions, and the above line is only protected. It eludes the
variance check because having type Nothing, the covariant parameter
doesn't appear in the result.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland