Type propagation analysis

[retronym]

Allows inlining non-final methods when the receiver is precisely known.

Miguel's code: TypeFlowAnalysis

[lrytz]

Note that the following already works without type analysis

class C { 
  @inline def f = 0
}
final class D extends C
class Test {
  def t(d: D) = d.f
}

Code generation emits the invocation d.f as INVOKEVIRTUAL D.f, even though f is declared in class C. The inliner already makes use of the more specific receiver type that is available.

However, there are cases where it helps to know if the receiver type is precise or not, which this doesn't give you:

class A { def f = 1 }
def test = (new A).f

[lrytz]

The analysis itself is implemented in scala/scala@e431978, but we still need to make use of it for inlining.

[lrytz]

done in scala/scala#7133