[jvm] fix self-recursing Object bridge for closures with non-Object typed return

When a closure's typed return is a specific reference type (e.g. SyncStats)
and a functional interface in the conversion set has an Object-erased
abstract method also named `invoke` — the shape of Function0<T>,
Callable<V> after erasure — the FI loop in jvmFunctions.generate_invoke
synthesized an `Object invoke()` bridge but pointed it at
(meth.name, meth.dargs, meth.dret). At that program point meth came from
register_signature with dret already declassified to Object, so the bridge
body emitted `invokevirtual invoke()Object` against itself. The later
`loop meth_typed` block that would have produced the proper Object→typed
bridge was then short-circuited by has_method (the slot was already taken).
First invocation StackOverflowError'd.

Forward to (meth.name, arg_sigs, ret) — the typed invoke that was actually
spawned earlier in generate_invoke — so the Object-returning bridge
dispatches to the real implementation and casts the result on return.

Repro shape (also added as a misc/jvm test extending StructuralSam):
  public interface GenericInvoke<T> { T invoke(); }
  Listeners.runGenericInvoke(() -> new Boxed(7));

Author: kLabz

src/generators/jvm/jvmFunctions.ml

@@ -411,7 +411,15 @@ class typed_function
 			let msig = method_sig jfi.jargs jfi.jret in
 			if not (jc_closure#has_method jfi.jname msig) then begin
 				let jm_invoke_next = spawn_invoke_next jfi.jname msig false in
-				functions#make_forward_method_jsig jc_closure jm_invoke_next meth.name jfi.jargs jfi.jret meth.dargs meth.dret
+				(* Forward to the typed invoke (arg_sigs, ret) rather than the
+				   Object-declassified (meth.dargs, meth.dret). When the FI's
+				   own method is also named "invoke" with an erased Object
+				   return (Function0<T>, Callable<V>, …), forwarding to
+				   meth.dret would emit `invokevirtual invoke()Object` against
+				   this very bridge and self-recurse — the later loop that
+				   would have synthesized the Object→typed bridge is then
+				   short-circuited by has_method. *)
+				functions#make_forward_method_jsig jc_closure jm_invoke_next meth.name jfi.jargs jfi.jret arg_sigs ret
 			end
 		) functional_interfaces;
 		let rec loop meth =

tests/misc/jvm/projects/StructuralSam/Main.hx

@@ -6,6 +6,7 @@ import test.Listeners.Listeners_WithDefaults;
 import test.Listeners.Listeners_StringMaker;
 import test.Listeners.Listeners_Unused;
 import test.Listeners.Listeners_CtorSam;
+import test.Listeners.Listeners_Boxed;
 
 function main() {
 	// Plain SAM — javac would accept the lambda directly.
@@ -50,6 +51,20 @@ function main() {
 	// emitted closure won't implement CtorOnly and this `new` call will
 	// ClassCastException at runtime.
 	new Holder().run();
+
+	// Generic SAM whose abstract method is `T invoke()` — same shape as
+	// kotlin.jvm.functions.Function0<T>. The closure's typed invoke returns
+	// Boxed (a specific class), but the FI bridge spawned for the erased
+	// `Object invoke()` slot was forwarded to (meth.name, meth.dargs,
+	// meth.dret) where meth.dret had already been declassified to Object — so
+	// the bridge body invoked itself rather than the typed invoke, and the
+	// later loop that would have emitted the proper Object→Boxed bridge was
+	// short-circuited by has_method. Calling cb.invoke() from Java therefore
+	// went into infinite recursion (StackOverflowError) instead of returning
+	// the Boxed instance. RideAssist crash repro: a `() -> SyncStats` closure
+	// passed to `new Thread(...)` against a classpath carrying both
+	// kotlin Function0<SyncStats> and j.u.c.Callable<SyncStats>.
+	trace(Listeners.runGenericInvoke(() -> new Listeners_Boxed(7)));
 }
 
 class Holder {

tests/misc/jvm/projects/StructuralSam/Setup.hx

@@ -17,5 +17,7 @@ function main() {
 		"test/Listeners$UnaryStringFn.class",
 		"test/Listeners$ArgOnly.class",
 		"test/Listeners$CtorOnly.class",
-		"test/Listeners$CtorSam.class"]);
+		"test/Listeners$CtorSam.class",
+		"test/Listeners$GenericInvoke.class",
+		"test/Listeners$Boxed.class"]);
 }

tests/misc/jvm/projects/StructuralSam/compile.hxml.stdout

@@ -1,13 +1,14 @@
 click=7
-Main.hx:12: ok
-Main.hx:15: v=3
-Main.hx:18: 25
-Main.hx:21: 11
-Main.hx:24: made-2
+Main.hx:13: ok
+Main.hx:16: v=3
+Main.hx:19: 25
+Main.hx:22: 11
+Main.hx:25: made-2
 ovl-click=1
-Main.hx:28: click
-Main.hx:29: hi!
+Main.hx:29: click
+Main.hx:30: hi!
 bound-click=99
-Main.hx:37: true
-Main.hx:38: false
+Main.hx:38: true
+Main.hx:39: false
 ctor=42
+Main.hx:67: boxed=7

tests/misc/jvm/projects/StructuralSam/project/test/Listeners.java

@@ -123,4 +123,27 @@ public static String overloaded(OnClick cb, int id) {
     public static String overloaded(UnaryStringFn cb, String s) {
         return cb.apply(s);
     }
+
+    // Generic SAM whose abstract method is named `invoke` and whose erased
+    // return type is Object — the shape of kotlin.jvm.functions.Function0<T>
+    // and similar interfaces. Probes a codegen bug in
+    // jvmFunctions.generate_invoke: the FI loop synthesizes a bridge for
+    // `Object invoke()` and forwards it to (meth.name, meth.dargs, meth.dret),
+    // but meth.dret is Object-declassified at that point — so the bridge body
+    // becomes `invokevirtual invoke()Object` against itself, and the later
+    // loop that would have emitted the proper Object→typed bridge is
+    // short-circuited by has_method. The first call StackOverflowErrors.
+    public interface GenericInvoke<T> {
+        T invoke();
+    }
+
+    public static String runGenericInvoke(GenericInvoke<Boxed> cb) {
+        return cb.invoke().describe();
+    }
+
+    public static class Boxed {
+        public final int value;
+        public Boxed(int value) { this.value = value; }
+        public String describe() { return "boxed=" + value; }
+    }
 }