Renaming methods in an abstract class does not rename all the components

[mattleibow]

Assume a Kotlin-generated class:

public abstract class ClockMark {
    public ClockMark plus-LRDsOJo(double duration) { ... }
}

Besides all the issues in #464 and #466 which I work around for now, I write this <attr /> element to rename the member:

<attr path="/api/package[@name='kotlin.time']/class[@name='ClockMark']/method[@name='minus-LRDsOJo' and count(parameter)=1 and parameter[1][@type='double']]" name="managedName">Minus</attr>

This element does rename the public component, but the name of the delegate is not changed accordingly - resulting in invalid C# code.

static Delegate cb_minus-LRDsOJo_D;
#pragma warning disable 0169
static Delegate GetMinus_DHandler ()
{
	if (cb_minus-LRDsOJo_D == null)
		cb_minus-LRDsOJo_D = JNINativeWrapper.CreateDelegate ((Func<IntPtr, IntPtr, double, IntPtr>) n_Minus_D);
	return cb_minus-LRDsOJo_D;
}

static IntPtr n_Minus_D (IntPtr jnienv, IntPtr native__this, double p0)
{
	global::Kotlin.Time.ClockMark __this = global::Java.Lang.Object.GetObject<global::Kotlin.Time.ClockMark> (jnienv, native__this, JniHandleOwnership.DoNotTransfer);
	return JNIEnv.ToLocalJniHandle (__this.Minus (p0));
}
#pragma warning restore 0169

// Metadata.xml XPath method reference: path="/api/package[@name='kotlin.time']/class[@name='ClockMark']/method[@name='minus-LRDsOJo' and count(parameter)=1 and parameter[1][@type='double']]"
[Register ("minus-LRDsOJo", "(D)Lkotlin/time/ClockMark;", "GetMinus_DHandler")]
public virtual unsafe global::Kotlin.Time.ClockMark Minus (double p0)
{
	const string __id = "minus-LRDsOJo.(D)Lkotlin/time/ClockMark;";
	try {
		JniArgumentValue* __args = stackalloc JniArgumentValue [1];
		__args [0] = new JniArgumentValue (p0);
		var __rm = _members.InstanceMethods.InvokeVirtualObjectMethod (__id, this, __args);
		return global::Java.Lang.Object.GetObject<global::Kotlin.Time.ClockMark> (__rm.Handle, JniHandleOwnership.TransferLocalRef);
	} finally {
	}
}

[jonpryor]

Horrifying thought: we emit:

[Register ("minus-LRDsOJo", "(D)Lkotlin/time/ClockMark;", "GetMinus_DHandler")]

The first parameter -- minus-LRDsOJo -- is used by JavaCallableWrapperGenerator so that it knows what Java method name to override, and this Is Not A Valid Java Identifier, but our generator...emits Java code!

WTF is supposed to happen here?

Is this ostensibly Kotlin "virtual" method not overridable by Java? Do we need to emit Kotlin to override such methods?

If true, the meaning of "Kotlin support" just keeps expanding in scope...

[jonpryor]

For future reference, we believe that the plus-LRDsOJo method is generated from the kotlin fragment:

abstract class ClockMark {
    open operator fun plus(duration: Duration): ClockMark { /* ... */ }
}

[jonpryor]

...and this belief is apparently unwarranted. Given this Kotlin code:

abstract class ClockMark {
  open operator fun plus(duration : Double) : ClockMark? {
    return null
  }
}

Compile the above using a Kotlin 1.3 compiler, and javap shows that the method is named plus, and no hyphens are present anywhere:

$ javap -l -verbose -private  -c -s ClockMark.class
...
public abstract class ClockMark
...
{
  public ClockMark plus(double);
...
  public ClockMark();
...
}

Turning operator fun plus into a fun plus -- making it not an operator -- and overloading plus() doesn't alter the name. Adding a default value does alter the method name, but only to append $default:

abstract class ClockMark {
  open fun plus(duration : Double = 42.0) : ClockMark? {
    return null
  }
}

Results in javap output:

public abstract class ClockMark
  public ClockMark plus(double);
  public static ClockMark plus$default(ClockMark, double, int, java.lang.Object);

I don't currently understand how or why hyphens would be present in method names. :-(

[jpobst]

Fixed in #497.

[brendanzagaeski]

Release status update

A new Preview version of Xamarin.Android has now been published that includes the fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix.

Fix included in Xamarin.Android 10.1.0.29.

Fix included on Windows in Visual Studio 2019 version 16.4 Preview 3. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.