Fix maxStack after inlining

The computed value was too large previously: inlining stores receiver
and argument values of the inlined method into locals.

A too large value doesn't cause any bugs, but data flow analyses would
allocate too large frames.

The test (InlinerTest.maxLocalsMaxStackAfterInline) didn't catch the
bug because it tested the methods of the wrong ClassNode. The
CodeGenTools.compileClasses method returns a ClassNode that is created
from the classfile byte array emitted by the compiler. This ClassNode
is a new object and unrelated to the ClassNode used in the compiler
backend. The test now takes the correct ClassNode from the hash map in
the backend's byteCodeRepository.

1 files changed, 4 insertions, 0 deletions

diff --git a/test/junit/scala/tools/nsc/backend/jvm/opt/InlinerTest.scala b/test/junit/scala/tools/nsc/backend/jvm/opt/InlinerTest.scala
index c6313a84d2..f085cc917b 100644
--- a/test/junit/scala/tools/nsc/backend/jvm/opt/InlinerTest.scala
+++ b/test/junit/scala/tools/nsc/backend/jvm/opt/InlinerTest.scala
@@ -72,6 +72,10 @@ class InlinerTest extends ClearAfterClass {
   def compile(scalaCode: String, javaCode: List[(String, String)] = Nil, allowMessage: StoreReporter#Info => Boolean = _ => false): List[ClassNode] = {
     InlinerTest.notPerRun.foreach(_.clear())
     compileClasses(compiler)(scalaCode, javaCode, allowMessage)
+    // Use the class nodes stored in the byteCodeRepository. The ones returned by compileClasses are not the same,
+    // these are created new from the classfile byte array. They are completely separate instances which cannot
+    // be used to look up methods / callsites in the callGraph hash maps for example.
+    byteCodeRepository.compilingClasses.valuesIterator.toList.sortBy(_.name)
   }
 
   def checkCallsite(callsite: callGraph.Callsite, callee: MethodNode) = {