Missing argument results in `java.lang.VerifyError`

[soronpo]

Compiler version

v3.7.3

Minimized code

https://scastie.scala-lang.org/vkYYO4LJRP6eiBaiDqpCdg

abstract class Foo[T](defaultValue: => T, arg1: Int = 1, arg2: Int = 2):
  def getValue: T = defaultValue

enum Baz:
  case E1, E2

object Baz extends Foo[Baz](Baz.E1, arg2 = 2)

@main def test = println(Baz.getValue)

Output

java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    Baz$.<init>()V @9: invokespecial
  Reason:
    Type uninitializedThis (current frame, stack[1]) is not assignable to 'Baz$'
  Current Frame:
    bci: @9
    flags: { flagThisUninit }
    locals: { uninitializedThis, integer }
    stack: { uninitializedThis, uninitializedThis }
  Bytecode:
    0000000: b200 22b6 0026 3c2a 2ab7 002a c000 2c1b
    0000010: b800 301b 05b7 0033 b1                 

	at main$package$.test(main.scala:9)
	at test.main(main.scala:9)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at sbt.Run.invokeMain(Run.scala:144)
	at sbt.Run.execute$1(Run.scala:94)
	at sbt.Run.$anonfun$runWithLoader$5(Run.scala:121)
	at sbt.Run$.executeSuccess(Run.scala:187)
	at sbt.Run.runWithLoader(Run.scala:121)
	at sbt.Run.run(Run.scala:128)
	at com.olegych.scastie.sbtscastie.SbtScastiePlugin$$anon$1.$anonfun$run$1(SbtScastiePlugin.scala:38)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
	at sbt.util.InterfaceUtil$$anon$1.get(InterfaceUtil.scala:32)
	at sbt.ScastieTrapExit$App.run(ScastieTrapExit.scala:258)
	at java.base/java.lang.Thread.run(Thread.java:840)

Expectation

Prints E1.
Note that if we add arg1 = 1 or remove arg2 in Baz it works as expected.

[som-snytt]

minimal

class C(i: Int = 42, j: Int = 27)

object X extends C(j = X.k):
  def k = 5

@main def test = println:
  X

It's not specific to enum rewrite but named args (when out of order).

[tanishiking]

I'm wondering if this code should even compile. The definition object X extends C(j = X.k) creates a circular dependency, as the object X depends on its own method (X.k) to initialize its superclass.

Maybe scalac should catch this during an earlier phase, like the typer for better error message?

(This is reproducible with Scala 2.13.17 btw).

---

It seems the culprit is the bytecode for X$ consutructor, the above Scala code in #24201 (comment) compiles to the following bytecode.

 javap -c -p X$.class
 
 Compiled from "i24201.scala"
  public final class X$ extends C implements java.io.Serializable {
    public static final X$ MODULE$;
  
    private X$();
      Code:
           0: aload_0
           1: invokevirtual #15                 // Method k:()I
           4: istore_1
           5: getstatic     #20                 // Field C$.MODULE$:LC$;
           8: invokevirtual #23                 // Method C$.$lessinit$greater$default$1:()I
          11: istore_2
          12: aload_0
          13: iload_2
          14: iload_1
          15: invokespecial #26                 // Method C."<init>":(II)V
          18: return

It begins with aload_0 followed immediately by invokevirtual #15 (calling Method k:()I), which is illegal because it attempts to call a virtual method on an uninitialized this. The superclass constructor, C.<init> (invokespecial #26), must be executed before virtual methods call on this.

However, it is impossible to call superclass constructor before invokevirtual because:

• (1) To initialize the superclass C, the program must first evaluate the parameter j, which requires calling X.k.
• (2) However, X.k is an instance method of X, which cannot be legally called until after its superclass constructor (C.<init>) has completed.

Maybe we should make it compile error at the earlier phase?

           0: aload_0 // push uninitialized `this` on the stack
           1: invokevirtual #15                 // calling Method k:()I with *uninitialized this*
           ....
           15: invokespecial #26              // This should come before invokevirtual. Method C."<init>":(II)V

[hamzaremmal]

I'm wondering if this code should even compile. The definition object X extends C(j = X.k) creates a circular dependency, as the object X depends on its own method (X.k) to initialize its superclass.

Maybe scalac should catch this during an earlier phase, like the typer for better error message?

/cc @liufengyun @olhotak

[liufengyun]

@olhotak @EnzeXing This is the case where we need to be more faithful to the concrete semantics: self-cycles is only safe after the super-call of a global object.

[olhotak]

If the question is whether this should compile, yes it should. Accesses to global objects are always allowed even if those objects have not yet been fully initialized.

But yes, we should make sure the global object initialization checker gives a warning for this.

[som-snytt]

The similar does not compile:

class C(i: Int = 42, j: Int = 27)

object X extends C(i = X.k):
  def k = 5

@main def test = println:
  X

fails with

4 |object X extends C(i = X.k):
  |                       ^^^
  |super constructor cannot be passed a self reference X.k unless parameter is declared by-name
1 error found
Compilation failed

so I assume something is confused by the named arg out of order.

If the Scala store had a t-shirt, I'd buy it:

self-cycles is only safe after the super-call of a global object!

Also, say it ten times fast.

[liufengyun]

Note that the check for named arg is not enough (even though it can make JVM verifier happy):

class C(j: Int)

object A:
  def foo = X.k

object X extends C(A.foo):
  def k = 5

@main def test = println:
  X

We get an runtime exception:

java.lang.ExceptionInInitializerError
	at main$package$.test(main.scala:10)
	at test.main(main.scala:9)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at sbt.Run.invokeMain(Run.scala:144)
	at sbt.Run.execute$1(Run.scala:94)
	at sbt.Run.$anonfun$runWithLoader$5(Run.scala:121)
	at sbt.Run$.executeSuccess(Run.scala:187)
	at sbt.Run.runWithLoader(Run.scala:121)
	at sbt.Run.run(Run.scala:128)
	at com.olegych.scastie.sbtscastie.SbtScastiePlugin$$anon$1.$anonfun$run$1(SbtScastiePlugin.scala:38)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
	at sbt.util.InterfaceUtil$$anon$1.get(InterfaceUtil.scala:32)
	at sbt.ScastieTrapExit$App.run(ScastieTrapExit.scala:258)
	at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.NullPointerException: Cannot invoke "X$.k()" because "X$.MODULE$" is null
	at A$.foo(main.scala:4)
	at X$.<init>(main.scala:6)
	at X$.<clinit>(main.scala:6)
	... 17 more

[tanishiking]

Thanks you everyone for the comments! Just to clarify:
The example below shouldn't compile and should produce an error like super constructor cannot be passed a self reference X.k unless parameter is declared by-name,

(1)

class C(i: Int = 42, j: Int = 27)

object X extends C(j = X.k):
  def k = 5

@main def test = println:
  X

And the original code should compile and generate a valid bytecode, correct?

(2)

abstract class Foo[T](defaultValue: => T, arg1: Int = 1, arg2: Int = 2):
  def getValue: T = defaultValue

enum Baz:
  case E1, E2

object Baz extends Foo[Baz](Baz.E1, arg2 = 2)

@main def test = println(Baz.getValue)

So, if I'm understanding correctly, the tasks are:

• To ensure that original code (2) generates valid bytecode.
• To make code (1) fail with a compile error in an earlier phase.

---

As @soronpo mentioned, it compiles to the valid bytecode when we didn't skip arg1.

object Baz extends Foo[Baz](Baz.E1, arg1 = 2)

  private Baz$();
    Code:
         0: aload_0
         1: invokestatic  #33                 // Method Baz$$superArg$1:()Lscala/Function0;
         4: iconst_2
         5: getstatic     #38                 // Field Foo$.MODULE$:LFoo$;
         8: invokevirtual #42                 // Method Foo$.$lessinit$greater$default$3:()I
        11: invokespecial #45                 // Method Foo."<init>":(Lscala/Function0;II)V
        14: return

while the original code (2) compiles to the wired invalid constructor: (7-15 should be redundant?)

  private Baz$();
    Code:
         // get default argument for `arg1` and store_1
         0: getstatic     #34                 // Field Foo$.MODULE$:LFoo$;
         3: invokevirtual #38                 // Method Foo$.$lessinit$greater$default$2:()I
         6: istore_1
         
         7: aload_0 // push uninitialized this for Foo."<init>
         // Trying to get `Baz.E1`? but aload_0 then invokespecial is invalid because it is uninitialized
         8: aload_0
         9: invokespecial #42                 // Method defaultValue$1$2:()LBaz;
        12: checkcast     #44                 // class scala/Function0
        15: iload_1

        // And why we're pushing the argments to the stack again???
        16: invokestatic  #48                 // Method Baz$$superArg$1:(Lscala/Function0;I)Lscala/Function0;
        19: iload_1
        20: iconst_2
        21: invokespecial #51                 // Method Foo."<init>":(Lscala/Function0;II)V
        24: return

Something seems to be confused around named args indeed 👀