Regression at dex2jar v65+ lambda adapter

[Claudemirovsky]

The commit 1096eeb introduces a bug regarding the signature of lambda methods.
How to reproduce:

Consider this code as the content of a file named Example.kt:

package example

fun main(args : Array<String>) {
    val data = runCatching { throw Exception() }.getOrElse { "bruh" }
    println(data)
}

Compile it to a .dex file, using d8:

$ kotlinc Example.kt -d example.jar
$ d8 example.jar 2>/dev/null

Using dex2jar-v64, the compiled dex can be converted back to a executable .jar file just fine:

$ ./dex-tools-v64/d2j-dex2jar.sh --output ok-result-v64.jar classes.dex
dex2jar classes.dex -> ok-result-v64.jar

$ kotlin -cp ok-result-v64.jar example.ExampleKt
bruh

But when using dex2jar-v65+, executing the generated jar file throws an NoSuchMethodError error:

$ ./dex-tools-v65/d2j-dex2jar.sh --output error-result-v65.jar classes.dex
dex2jar classes.dex -> error-result-v65.jar

$ kotlin -cp error-result-v66.jar example.ExampleKt
Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.Object kotlin.Result.constructor_impl(java.lang.Object)'
        at example.ExampleKt.main(Unknown Source)
        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 org.jetbrains.kotlin.runner.AbstractRunner.run(runners.kt:70)
        at org.jetbrains.kotlin.runner.Main.run(Main.kt:194)

I don't know if this only affects Kotlin lambdas, or if Java lambdas are also affected.

Java 17.0.8 / Kotlin 1.9.20

[Claudemirovsky]

Related with #27.
(Didn't see it before, lol)

[ThexXTURBOXx]

Closing in favor of #27