SI-3832 Don't lift methods in aux constructor trailing stats as STATIC

SI-1909 modified LambdaLift to lift in auxiliary constructors methods as STATIC
so they could be called before the self-constructor was called.

That allowed for:

     class Foo (x: Int) {
       def this() = this( {
         def bar() = 5
         bar
       })
    }

However, if the method is in a statement that trails the self constructor call,
this is unnecessary and in fact incorrect as it robs the lifted method of `this`.

This commit uses the machinery established in SI-6666 to limit the STATIC-ness
of lifted methods to those used in arguments for self-constructor calls.

This is used exclusively; the `isAuxillaryConstructor` check wasn't the right
way to solve this, as was seen by the regression it caused in SI-3832.
A new test case shows that we can statically lift methods in super-constructor
calls, rather than just self-constructor calls.

We also have to avoid statically lifting objects in these positions. For now,
I just emit a dev warning that a VerifyError is in your future. With some more
thought we could escalate that to a implementation restriction and emit an error.

1 files changed, 9 insertions, 0 deletions

diff --git a/test/files/run/t1909c.scala b/test/files/run/t1909c.scala
new file mode 100644
index 0000000000..87c0eb08b5
--- /dev/null
+++ b/test/files/run/t1909c.scala
@@ -0,0 +1,9 @@
+class Base(a: Any)
+
+// java.lang.VerifyError: (class: Sub, method: <init> signature: ()V) Expecting to find object/array on stack
+//  at Test$.<init>(t1909c.scala)
+class Sub() extends Base({ def bippy = 5; bippy })
+
+object Test extends App {
+  new Sub()
+}