[jnimarshalmethod-gen] Create delegate types for marshaling methods with 15+ parameters

[radekdoulik]

Context: https://github.com/xamarin/java.interop/issues/709

Generate delegate types for marshaling methods. We generate them
in cases where we cannot use Func<> or Action<> delegates
because of too many parameters (more than 14) and when we don't
have special custom delegate type available - like
_JniMarshal_PPZBCSIJFDLLLLLDFJ_Z delegate type in our tests.

Let the TypeMover move these delegate types to the original
assembly as well.

Added test to check marshaling with auto-generated delegate types.

Example of generated delegate type:

.class private auto ansi sealed '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'
extends [mscorlib]System.MulticastDelegate
{
.method public hidebysig specialname rtspecialname instance void .ctor(object A_1,
native int A_2) runtime managed
{
} // end of method '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'::.ctor
.method public hidebysig newslot virtual instance bool Invoke(native int A_1,
native int A_2,
bool A_3,
int8 A_4,
char A_5,
int16 A_6,
int32 A_7,
int64 A_8,
float32 A_9,
float64 A_10,
native int A_11,
native int A_12,
native int A_13,
native int A_14,
native int A_15,
float64 A_16,
float32 A_17,
int64 A_18,
int32 A_19,
int32 A_20) runtime managed
{
} // end of method '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'::Invoke
.method public hidebysig newslot virtual instance [mscorlib]System.IAsyncResult BeginInvoke(native int A_1,
native int A_2,
bool A_3,
int8 A_4,
char A_5,
int16 A_6,
int32 A_7,
int64 A_8,
float32 A_9,
float64 A_10,
native int A_11,
native int A_12,
native int A_13,
native int A_14,
native int A_15,
float64 A_16,
float32 A_17,
int64 A_18,
int32 A_19,
int32 A_20,
[mscorlib]System.AsyncCallback A_21,
object A_22) runtime managed
{
} // end of method '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'::BeginInvoke
.method public hidebysig newslot virtual instance bool EndInvoke([mscorlib]System.IAsyncResult A_1) runtime managed
{
} // end of method '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'::EndInvoke
} // end of class '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'

An example of the optimized code in the registration __<$>_jni_marshal_methods'::__RegisterNativeMembers method:

...
IL_0181: dup
IL_0182: ldc.i4.s 11
IL_0184: ldstr "staticManyParametersWithAutogeneratedDelegateType"
IL_0189: ldstr "(ZBCSIJFDLjava/lang/Object;Ljava/lang/String;Ljava"
+ "/util/ArrayList;Ljava/lang/String;Ljava/lang/Object;DFJII)I"
IL_018e: ldnull
IL_018f: ldftn int32 Java.InteropTests.ExportTest/'__<$>_jni_marshal_methods'::staticManyParametersWithAutogeneratedDelegateType(native int,
native int,
bool,
int8,
char,
int16,
int32,
int64,
float32,
float64,
native int,
native int,
native int,
native int,
native int,
float64,
float32,
int64,
int32,
int32)
IL_0195: newobj instance void '__<$>_jni_marshal_LLZBCSIJFDLLLLLDFJII_I'::.ctor(object,
native int)
IL_019a: newobj instance void [Java.Interop]Java.Interop.JniNativeMethodRegistration::.ctor(string,
string,
[mscorlib]System.Delegate)
IL_019f: stelem [Java.Interop]Java.Interop.JniNativeMethodRegistration
...

[jonpryor]

Is there a reason to generate these new __<$>_jni_marshal_-prefixed delegate types instead of using the same types -- or same naming convention? -- as the _JniMarshal_-prefixed types?

[jonpryor]

…I ask because I'm wondering if there's some way to not add this public export, or at least find a "more suitable" location for it?

[jonpryor]

I don't understand how this method differs from the existing "lots of parameters" test:

https://github.com/xamarin/java.interop/blob/03c227228955622511bafabe61a12e30e45dc6f7/tests/Java.Interop.Export-Tests/Java.Interop/ExportTest.cs#L109-L162

How does this (pair of) method(s) differ from the current ExportType.staticFuncThisMethodTakesLotsOfParameters() method? They both have lots of parameters, and they both appear to have "similar" [JavaCallable] custom attribute values. How does this test differ?

[jonpryor]

Do we need to declare BeginInvoke() and EndInvoke() if these are generated types, with type names that are "inaccessible", and jnimarshalmethod-genisn't emitting references to these methods?

[jonpryor]

Closing as this is largely moot as of #1046 + dependencies.