You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// (1) A non-final method can be safe to inline if the receiver type is a final subclass. Example:
301
+
// (1) Special case for trait super accessors. trait T { def f = 1 } generates a static
302
+
// method t$ which calls `invokespecial T.f`. Even if `f` is not final, this call will
303
+
// always resolve to `T.f`. This is a (very) special case. Otherwise, `invokespecial`
304
+
// is only used for private methods, constructors and super calls.
305
+
//
306
+
// (2) A non-final method can be safe to inline if the receiver type is a final subclass. Example:
303
307
// class A { @inline def f = 1 }; object B extends A; B.f // can be inlined
304
308
//
305
-
// TODO: (1) doesn't cover the following example:
309
+
// TODO: (2) doesn't cover the following example:
306
310
// trait TravLike { def map = ... }
307
311
// sealed trait List extends TravLike { ... } // assume map is not overridden
308
312
// final case class :: / final case object Nil
@@ -316,9 +320,10 @@ abstract class CallGraph {
316
320
// TODO: type analysis can render more calls statically resolved. Example:
317
321
// new A.f // can be inlined, the receiver type is known to be exactly A.
318
322
valisStaticallyResolved:Boolean= {
319
-
isNonVirtualCall(call) ||// scala/scala-dev#86: super calls (invokespecial) can be inlined -- TODO: check if that's still needed, and if it's correct: scala-dev#143
0 commit comments