[XA.Tools.Bytecode] Add Kotlin support to our binding process.

[jpobst]

Various fixes and enhancements to allow better default Kotlin libraries bindings.

• Hide Kotlin-internal classes, constructors, and methods.
• Hide implementation methods (*-impl*).
• Rename extension method parameter like $this$decodeBase64 to obj.
• Use Kotlin provided method parameter names instead of p0, p1, etc.
• Rename any method with a hyphen-<hashcode> to drop the invalid part (add-H4uI21a -> add).
  • This is how Kotlin ensures add (UInt) and add (Int) don't clash when compiled to Java.

[jonpryor]

The last bullet point gives me some pause:

Rename any method with a hyphen-<hashcode> to drop the invalid part (add-H4uI21a -> add).

Does this happen with virtual instance members?

I fear the answer is "yes".

Thus, consider the Kotlin code:

classExampleBase {
publicopenfunfoo(value:Int) {
}
publicopenfunfoo(value:UInt) {
}
}

Compile & Disassemble it, and:

$ kotlinc hello.kt
$ javap -s ExampleBase.class Compiled from "hello.kt"
public final class ExampleBase {
public void foo(int);
descriptor: (I)V
public void foo-WZ4Q5Ns(int);
descriptor: (I)V
public ExampleBase();
descriptor: ()V
}

Based on the bullet point, I think we'd bind this as:

[Register("ExampleBase",DoNotGenerateAcw=true)]partialclassExampleBase{[Register("foo", ...)]publicvirtualvoidFoo(intvalue){_members.InstanceMethods.InvokeVirtualVoidMethod("foo.(I)V",this, ...);}[Register("foo-WZ4Q5Ns", ...)]publicvirtualvoidFoo(intvalue){_members.InstanceMethods.InvokeVirtualVoidMethod("foo-WZ4Q5Ns.(I)V",this, ...);}}

At which point I scratch my head.

For starters, that can't compile: there's two Foo(int) methods.

Even if it could compile, the ExampleBase.foo(UInt) method cannot be overridden from C#, because we use Java as an intermediary:

// C#classMyDerivedExample:ExampleBase{// Assume we "somehow" override the foo(UInt) overloadpublicoverridevoidFoo(intvalue){}}

There's not actually any way to override ExampleBase.foo(UInt).

Now, if we bound ExampleBase.foo(UInt) as a non-virtual method, we avoid this conundrum, and we allow it to be invoked, because JniPeerMembers doesn't care about dashes and such.

As-is, though, I cannot tell what this PR would do with the above Kotlin class. Is this already handled and I just don't see it? Should it be addressed?

[jpobst]

Yeah, that appears to be an issue that we will need to think through and fix. Perhaps if we have a foo (int) and a foo-abcdefa (int) we can just drop the second one? Or we could make the assumption that it's uint and generate foo (uint)?

Given that it is likely a rare corner case (that could be fixable via metadata if encountered) my inclination is to commit this as-is and add a new issue for this.