Consider type declaration order in MethodImpls

[MichalStrehovsky]

This fixes the Loader\classloader\InterfaceFolding\Ambiguous test.

For the following program in pseudo-C# (test is in IL since this is not valid C#):

B<int, int> b = new B<int, int>();
if (!(((I<int>)b).Foo() != "B::Foo2"))
{
    B<string, string> b2 = new B<string, string>();
    if (!(((I<string>)b2).Foo() != "B::Foo2"))
    {
        Console.WriteLine("Pass");
        return 100;
    }
}

Console.WriteLine("Failed!");
return -1;

interface I<T>
{
    string Foo();
}

class A<U> : I<U>
{
    string I<U>.Foo() => "A::Foo";
}

internal class B<V, W> : A<V>, I<W>
{
    string I<W>.Foo() => "B::Foo1";
    string I<V>.Foo() => "B::Foo2";
}

We incorrectly resolve the interface call into B::Foo1 because I<int>.Foo could be implemented by both Foo1 and Foo2 methods and we just pick whatever we see first. Per ECMA-335: "If there are multiple methods for the same interface method (i.e. with different generic type parameters), place them in the list in type declaration order of the associated interfaces."

This implements the tie break.

Cc @dotnet/ilc-contrib

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/coreclr/tools/Common/TypeSystem/Common/MetadataVirtualMethodAlgorithm.cs:280

• The new method FindInterfaceImplFromDeclFromMethodImpls is introduced without corresponding test cases. Ensure that this method is covered by tests.

private static MethodDesc FindInterfaceImplFromDeclFromMethodImpls(MetadataType type, MethodDesc decl)

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MichalStrehovsky]

The crash in https://helix.dot.net/api/2019-06-17/jobs/cbb9e7e4-8a5d-4034-831f-f689a4eb08c9/workitems/Microsoft.Extensions.Hosting.WindowsServices.Tests/console is a crash on shutdown. Going to assume it's another instance of the UCRT by-design bug #108640.

[davidwrighton]

Looks ok. I don't like taking changes here, but I don't see anything wrong with this.