[generator] Drop Kotlin hash-mangled siblings that collide on the C# side (#1432)

Context: step (1) of #1431.

When Kotlin compiles a function whose parameter is an `@JvmInline value
class`, the JVM-level name is mangled with a 7-char hash suffix, e.g.
`tint-Rn_QMJI(J)V`. `KotlinFixups` already strips that suffix so the C#
binding sees `Tint(long)` instead of an unspellable name.

The problem: two distinct Kotlin overloads that take different inline
classes erase to the *same* JVM signature, differing only in the hash.
Jetpack Compose hits this constantly (`Color`, `TextUnit`, `Dp` all wrap
`ULong`/`Long`/`Float`). For example:

    @JvmInline value class MyColor(val value: ULong)
    @JvmInline value class MyAlpha(val value: ULong)

    object Widgets {
        fun tint(color: MyColor) { }
        fun tint(alpha: MyAlpha) { }
    }

`javap` shows two hash-distinct siblings with identical erased shape:

    public static void tint-Rn_QMJI(long);   // MyColor
    public static void tint-uzYZ1wI(long);   // MyAlpha

After the existing rename both become `Tint(long)`, and `generator`
emits something like:

    // Before: CS0111, build broken
    public static void Tint (long color) { ... }
    public static void Tint (long alpha) { ... }

This change detects post-rename collisions inside `KotlinFixups`, keeps
the first method deterministically, drops the rest, and emits a new
`BG8C02` warning so the user can override the choice via Metadata.xml:

    // After: one overload kept, warning emitted
    public static void Tint (long color) { ... }
    // warning BG8C02: For type 'Widgets', the Kotlin name-mangled method
    // 'Tint' (originally 'tint-uzYZ1wI') has multiple hash-suffixed
    // siblings that erase to the same C# signature. Only the first will
    // be emitted; remove the duplicate via Metadata.xml to suppress this
    // warning.

Non-colliding hash-mangled siblings (different arity, or different
underlying primitive) still survive — e.g. `pad(MyDp)` and
`pad(MyDp, MyDp)` both bind, and `tint(MyDp)` survives alongside one of
the `tint(long)` overloads because they differ in raw type (`F` vs `J`).

Step (2) of #1431 — projecting inline-class parameters as their own
strongly-typed wrappers so all overloads can coexist — is left for a
follow-up.

Real Kotlin/Gradle fixture
--------------------------

To exercise this against real Kotlin compiler output (not hand-written
`.class` files), add a small Gradle project under
`tests/Xamarin.Android.Tools.Bytecode-Tests/kotlin-gradle/`:

  * `build.gradle.kts` pins Kotlin 2.0.21 / JVM 17 and emits `.class`
    files into `$rootDir/classes`.
  * `src/main/kotlin/InlineClassCollisions.kt` declares the value
    classes and `Widgets` object shown above.
  * A new MSBuild target `BuildKotlinGradleProject` invokes the
    existing `build-tools/gradle/gradlew(.bat)` (no duplicate wrapper)
    with `-p kotlin-gradle classes` before `BeforeCompile`. The
    produced `.class` files are then embedded as test resources.
  * The `classes/` and `build/` outputs stay out of git via
    `kotlin-gradle/.gitignore`.

A `.gitattributes` entry forces `gradlew`, `*.properties`, `*.kt`, and
`*.kts` to LF so the shared wrapper script keeps working on Unix.

Tests
-----

  * `KotlinFixupsTests`: 3 new unit tests cover the collision /
    no-collision / mixed cases with a `WarningCapture` helper that
    asserts on BG8C02.
  * `KotlinInlineClassCollisionTests`: 3 new tests load the freshly
    Gradle-built `Widgets.class` / `MyColor.class` and assert the
    expected JVM-level mangling, so we'd notice if Kotlin ever changed
    the scheme.

All 5 `KotlinFixupsTests`, all 78 Bytecode tests, and all 453 generator
tests pass.

### Address PR review feedback

- KotlinFixups.RemoveCollidingSiblings: collide mangled methods against
  every other method on the type (not only other mangled siblings), so a
  mangled tint(MyInlineLong) collapsing to tint(long) collides with a
  pre-existing non-mangled tint(long) too. Mangled methods are still the
  only thing ever dropped.
- Add MangledMethod_CollidesWithNonMangledOverload test for that case.
- Mark the BG8C02-asserting tests [NonParallelizable] because they mutate
  the global Report.OutputDelegate, matching the convention used by other
  WarningCapture-style tests in the suite.
- Bytecode-Tests.targets: use shared $(GradleWPath) / $(GradleArgs)/
  EnvironmentVariables=JAVA_HOME pattern from Directory.Build.props,
  matching tools/java-source-utils. Removes the ad-hoc OS-switch wrapper
  selection and makes the Gradle invocation work in environments without
  java on PATH.
- build.gradle.kts: drop jvmToolchain(17) so Gradle uses the JDK the
  caller already configured via JAVA_HOME (auto-provisioning fails in CI
  environments without download repositories).

### Keep first colliding sibling, not last

The previous fix in 8e8d7a6 walked all of gen.Methods when looking
for a conflict and removed the *current* mangled method whenever any
other method matched -- including ones that appeared LATER in source.
For two mangled siblings A and B, iterating A would find B (later) and
remove A, leaving B as the survivor. That contradicted the warning text
('Only the first will be emitted') and was non-deterministic w.r.t. the
intended Metadata.xml escape hatch.

Fix: only treat the current mangled method as the duplicate when a
matching method appears EARLIER in source order (TakeWhile(m => m !=
method)). This guarantees the first-declared overload always wins,
whether the earlier method is mangled or non-mangled.

Strengthened CollidingHashSiblings_AreDeduplicated to assert the kept
method's JavaName is �dd-AAAAAAA (not just any method named Add).

### Drop mangled when non-mangled overload matches in any order

When a mangled method appears BEFORE a non-mangled overload with the
same erased signature, the previous TakeWhile-only logic kept both
(neither was earlier than itself, and non-mangled methods were never
in 'renamed'), producing CS0111.

Always prefer dropping the mangled method whenever ANY non-mangled
match exists regardless of source order. Fall back to the
first-declared-wins rule only when the only collisions are between
mangled siblings.

Adds MangledMethod_CollidesWithNonMangledOverload_ReversedOrder test
covering the previously-broken ordering.

### Compile Kotlin in-process to fix macOS CI failure

On macOS the external Kotlin compile daemon fails to start on attempt
#1 and prints 'e : The daemon has terminated unexpectedly...' to
stderr. Kotlin retries successfully (BUILD SUCCESSFUL), but the stray
'e :' line plus the daemon JVM shutdown causes the gradlew process to
exit -1, failing the dotnet build.

Setting kotlin.compiler.execution.strategy=in-process makes Kotlin
compile inside the Gradle daemon process itself, avoiding the extra
JVM and the macOS flake entirely.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: jonathanpeppers

.gitattributes

@@ -35,3 +35,9 @@ Makefile	eol=lf
 *.wixproj	eol=crlf
 *.wxs	eol=crlf
 *.rtf	eol=crlf
+
+# Gradle wrapper must stay LF on all platforms (executed under Bash on Unix)
+gradlew	eol=lf
+*.properties	eol=lf
+*.kt	eol=lf
+*.kts	eol=lf

src/Java.Interop.Localization/Resources.Designer.cs

@@ -308,6 +308,10 @@ The following terms should not be translated: Metadata.xml, path.</comment>
     <value>For type '{0}', base interface '{1}' is invalid.</value>
     <comment>{0}, {1} - .NET types.</comment>
   </data>
+  <data name="Generator_BG8C02" xml:space="preserve">
+    <value>For type '{0}', the Kotlin name-mangled method '{1}' (originally '{2}') has multiple hash-suffixed siblings that erase to the same C# signature. Only the first will be emitted; remove the duplicate via Metadata.xml to suppress this warning.</value>
+    <comment>{0} - .NET type. {1} - C# method name. {2} - Original (mangled) JVM method name.</comment>
+  </data>
   <data name="JavaCallableWrappers_XA4200" xml:space="preserve">
     <value>Cannot generate Java wrapper for type '{0}'. Only 'class' types are supported.</value>
     <comment>{0} - Java type.

src/Java.Interop.Localization/Resources.resx

@@ -74,6 +74,7 @@ public LocalizedMessage (int code, string value)
 		public static LocalizedMessage WarningUnknownGenericConstraint => new LocalizedMessage (0x8B00, Localization.Resources.Generator_BG8B00);
 		public static LocalizedMessage WarningBaseInterfaceNotFound => new LocalizedMessage (0x8C00, Localization.Resources.Generator_BG8C00);
 		public static LocalizedMessage WarningBaseInterfaceInvalid => new LocalizedMessage (0x8C01, Localization.Resources.Generator_BG8C01);
+		public static LocalizedMessage WarningKotlinNameMangledCollision => new LocalizedMessage (0x8C02, Localization.Resources.Generator_BG8C02);
 
 		public static void LogCodedErrorAndExit (LocalizedMessage message, params string [] args)
 			=> LogCodedErrorAndExit (message, null, null, args);

src/Java.Interop.Tools.Generator/Utilities/Report.cs

@@ -0,0 +1,70 @@
+using System;
+using System.Linq;
+using NUnit.Framework;
+using Xamarin.Android.Tools.Bytecode;
+
+namespace Xamarin.Android.Tools.BytecodeTests
+{
+	// Exercises the real Kotlin bytecode produced by the Gradle fixture under
+	// kotlin-gradle/ to confirm that the JVM-level mangling we expect (and that
+	// the generator's KotlinFixups must now de-collide) is actually what kotlinc
+	// emits for @JvmInline value-class parameters. See dotnet/java-interop#1431.
+	[TestFixture]
+	public class KotlinInlineClassCollisionTests : ClassFileFixture
+	{
+		[Test]
+		public void Widgets_HasCollidingHashMangledSiblings ()
+		{
+			var klass = LoadClassFile ("Widgets.class");
+
+			// Kotlin emits one mangled method per inline-class overload:
+			//   tint-<hash>(J)V    for MyColor (ULong-backed)
+			//   tint-<hash>(J)V    for MyAlpha (ULong-backed) — collides with MyColor
+			//   tint-<hash>(F)V    for MyDp    (Float-backed) — unique
+			var tints = klass.Methods
+				.Where (m => m.Name.StartsWith ("tint-", StringComparison.Ordinal))
+				.ToList ();
+
+			Assert.AreEqual (3, tints.Count, "Expected three `tint-<hash>` overloads from the Gradle fixture.");
+
+			var longTints = tints.Where (m => m.Descriptor == "(J)V").ToList ();
+			Assert.AreEqual (2, longTints.Count,
+				"Expected two `tint-<hash>(J)V` siblings (MyColor + MyAlpha) — this is the multi-sibling collision case from dotnet/java-interop#1431.");
+
+			Assert.AreEqual (1, tints.Count (m => m.Descriptor == "(F)V"),
+				"Expected one unique `tint-<hash>(F)V` (MyDp) that should survive deduplication.");
+		}
+
+		[Test]
+		public void Widgets_HasNonCollidingHashMangledOverloads ()
+		{
+			var klass = LoadClassFile ("Widgets.class");
+
+			var pads = klass.Methods
+				.Where (m => m.Name.StartsWith ("pad-", StringComparison.Ordinal))
+				.ToList ();
+
+			Assert.AreEqual (2, pads.Count);
+			CollectionAssert.AreEquivalent (
+				new [] { "(F)F", "(FF)F" },
+				pads.Select (m => m.Descriptor).ToArray (),
+				"`pad` overloads have distinct JVM signatures and should both survive after rename.");
+		}
+
+		[Test]
+		public void InlineClasses_AreEmittedAsValueClasses ()
+		{
+			// Sanity check that @JvmInline really produced a JvmInline annotation on
+			// the inline-class type — this is what step (2) of #1431 will key on.
+			var myColor = LoadClassFile ("MyColor.class");
+
+			var annotations = myColor.Attributes
+				.OfType<RuntimeVisibleAnnotationsAttribute> ()
+				.SelectMany (a => a.Annotations)
+				.Select (a => a.Type)
+				.ToList ();
+
+			Assert.Contains ("Lkotlin/jvm/JvmInline;", annotations);
+		}
+	}
+}

tests/Xamarin.Android.Tools.Bytecode-Tests/KotlinInlineClassCollisionTests.cs

@@ -25,7 +25,13 @@
 
   <ItemGroup>
     <EmbeddedResource Include="Resources\*" />
-    <EmbeddedResource Include="kotlin*\**\*.class" />
+    <EmbeddedResource Include="kotlin\**\*.class" />
+    <EmbeddedResource Include="kotlin-ThirdParty\**\*.class" />
+
+    <EmbeddedResource Include="kotlin-gradle\classes\xat\bytecode\tests\Widgets.class" LogicalName="Xamarin.Android.Tools.BytecodeTests.kotlin-gradle.Widgets.class" />
+    <EmbeddedResource Include="kotlin-gradle\classes\xat\bytecode\tests\MyColor.class" LogicalName="Xamarin.Android.Tools.BytecodeTests.kotlin-gradle.MyColor.class" />
+    <EmbeddedResource Include="kotlin-gradle\classes\xat\bytecode\tests\MyAlpha.class" LogicalName="Xamarin.Android.Tools.BytecodeTests.kotlin-gradle.MyAlpha.class" />
+    <EmbeddedResource Include="kotlin-gradle\classes\xat\bytecode\tests\MyDp.class" LogicalName="Xamarin.Android.Tools.BytecodeTests.kotlin-gradle.MyDp.class" />
 
     <EmbeddedResource Include="$(IntermediateOutputPath)classes\com\xamarin\NotNullClass.class" />
     <EmbeddedResource Include="$(IntermediateOutputPath)classes\com\xamarin\IJavaInterface.class" />

tests/Xamarin.Android.Tools.Bytecode-Tests/Xamarin.Android.Tools.Bytecode-Tests.csproj

@@ -5,6 +5,12 @@
     <TestJarNoParameters Include="java/**/*NoParameters.java" />
     <TestJar Include="java\**\*.java" Exclude="@(TestJarNoParameters);java\android\annotation\NonNull.java;" />
     <TestKotlinJar Include="kotlin\**\*.kt" />
+    <TestKotlinGradleSource Include="kotlin-gradle\src\**\*.kt;kotlin-gradle\*.gradle.kts" />
+    <TestKotlinGradleOutput Include="kotlin-gradle\classes\xat\bytecode\tests\Widgets.class" />
+    <TestKotlinGradleOutput Include="kotlin-gradle\classes\xat\bytecode\tests\MyColor.class" />
+    <TestKotlinGradleOutput Include="kotlin-gradle\classes\xat\bytecode\tests\MyAlpha.class" />
+    <TestKotlinGradleOutput Include="kotlin-gradle\classes\xat\bytecode\tests\MyDp.class" />
+    <TestKotlinGradleOutput Include="kotlin-gradle\classes\xat\bytecode\tests\InlineClassCollisionsKt.class" />
   </ItemGroup>
 
   <ItemGroup>
@@ -34,6 +40,25 @@
     <Exec Command="&quot;$(KotlinCPath)&quot; @(TestKotlinJar->'%(Identity)', ' ') -d &quot;kotlin&quot;" />
   </Target>
 
+  <!--
+      Build the real Kotlin/Gradle fixture in kotlin-gradle\ using the shared
+      Gradle wrapper from build-tools/gradle. Unlike BuildKotlinClasses above,
+      this is run unconditionally (a JDK is already required for BuildClasses),
+      so the .class files do not need to be committed. The wrapper downloads
+      Gradle + Kotlin on first run.
+  -->
+  <PropertyGroup>
+    <_KotlinGradleProjectDir>$(MSBuildThisFileDirectory)kotlin-gradle</_KotlinGradleProjectDir>
+  </PropertyGroup>
+
+  <Target Name="BuildKotlinGradleProject"
+        BeforeTargets="BeforeCompile"
+        Inputs="@(TestKotlinGradleSource)"
+        Outputs="@(TestKotlinGradleOutput)">
+    <Exec Command="&quot;$(GradleWPath)&quot; $(GradleArgs) -p &quot;$(_KotlinGradleProjectDir)&quot; classes"
+          EnvironmentVariables="JAVA_HOME=$(JavaSdkDirectory);APP_HOME=$(GradleHome)" />
+  </Target>
+
   <Target Name="BuildJar"
       AfterTargets="BuildClasses"
       Inputs="@(_BuildClassOutputs)"

tests/Xamarin.Android.Tools.Bytecode-Tests/Xamarin.Android.Tools.Bytecode-Tests.targets

@@ -0,0 +1,4 @@
+# Gradle build outputs - rebuilt from source on every test build.
+.gradle/
+build/
+classes/

tests/Xamarin.Android.Tools.Bytecode-Tests/kotlin-gradle/.gitignore

@@ -0,0 +1,21 @@
+plugins {
+    kotlin("jvm") version "2.0.21"
+}
+
+repositories {
+    mavenCentral()
+}
+
+// Don't pin a jvmToolchain -- it would force Gradle to auto-provision a
+// matching JDK and fail in CI environments without download repositories
+// configured. Use whatever JDK the caller already set in JAVA_HOME (the
+// .NET build forwards $(JavaSdkDirectory) for consistency with the rest
+// of the repo). Kotlin 2.0.21 targets JVM 11 by default, which is fine
+// for the bytecode the tests inspect.
+
+// Emit compiled classes into a stable, predictable location so the
+// .NET test harness can load them via ClassFileFixture without needing
+// to know the Gradle build directory layout.
+tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>("compileKotlin") {
+    destinationDirectory.set(file("$rootDir/classes"))
+}

tests/Xamarin.Android.Tools.Bytecode-Tests/kotlin-gradle/build.gradle.kts

@@ -0,0 +1,5 @@
+# Compile Kotlin in-process to avoid the macOS CI flake where the
+# external Kotlin compile daemon fails to start on attempt #1, emits an
+# `e :` line to stderr (which dotnet/Exec treats as an error and exit -1)
+# even though gradle reports BUILD SUCCESSFUL after the retry.
+kotlin.compiler.execution.strategy=in-process