Implementation of a static virtual method in a derived type is not found when there is a re-abstraction of the same method higher in inheritance hierarchy

[AlekseyTs]

Description

Implementation of a static virtual method in a derived type is not found when there is a re-abstraction of the same method higher in inheritance hierarchy

Reproduction Steps

https://sharplab.io/#v2:C4LgTgrgdgPgAgJgAQBUCmBnYBGJIkCSCAsAFADeZZSNSc2AbHQCxICyAhgJZQAUAlNVqVStMakzAAPOizYAfAIDcQmgF8qo2vSZxWs6VwUCkAdwAWaMGiRG8hbKqQinYowDo22ZU42knOiwOnt6CWjQi4trY7vQAnLwARAYxXon8KuFIfn5kcADMtlDAVgBmHADGNgSOFAGMSBwARlhglcBBXj6kuaQFRSVg5VWEyPg1ZJHRTM2t7UE1Id1+QA=

Compile and run:

class Test1 : I2
{

    static void Main()
    {
        Test<Test1>();
    }

    static void Test<i1>() where i1 : I1
    {

        i1.M1();
    }

    static void I1.M1()
    {
        System.Console.WriteLine("Test1.M1");
    }
}

public interface I1
{
    static abstract void M1();
}

public interface I2 : I1
{
    static abstract void I1.M1();
}

Expected behavior

"Test1.M1" is printed

Actual behavior

System.MissingMethodException: Method not found: 'Void I1.M1()'.
at System.Reflection.RuntimeAssembly.get_EntryPoint()
at SharpLab.Container.Execution.ExecuteCommandHandler.ExecuteAssembly(Byte[] assemblyBytes) in

Regression?

No response

Known Workarounds

Remove re-abstraction of the method in I2 to observe expected behavior.

Configuration

No response

Other information

Here is another flavor of the problem:
https://sharplab.io/#v2:C4LgTgrgdgPgAgJgAQBUCmBnYBGJIkCSAzALABQA3ueUrUnNgGz0AsSAsgIYCWUAFAEoadKmTrjUmYAB50WbAD5BAbmG0AvtTF0GzOGzkzuiwUgDuACzRg0SY3kLY1SUc/HGAdO2wrnmsv7kcER2UMDWAGacAMa2BE6UzrpInABGWGAxwKwcPgKqAVrBoeFgUbGEyPjx5KLiyWkZWTnxXnkFgWTFvKXlcSHVCLVJTC3YbYLOdRK0DB4MAJx8AETEbcv5fuT+QA==

class Test1 : I3
{

    static void Main()
    {
        Test<Test1>();
    }

    static void Test<i1>() where i1 : I1
    {

        i1.M1();
    }
}

public interface I1
{
    static abstract void M1();
}

public interface I2 : I1
{
    static abstract void I1.M1();
}

public interface I3 : I2
{
    static void I1.M1()
    {
        System.Console.WriteLine("I3.M1");
    }
}

Expected:

I3.M1

Actual:

System.MissingMethodException: Method not found: 'Void I1.M1()'.
   at System.Reflection.RuntimeAssembly.get_EntryPoint()
   at SharpLab.Container.Execution.ExecuteCommandHandler.ExecuteAssembly(Byte[] assemblyBytes) in 

[AlekseyTs]

@davidwrighton, @trylek FYI

[trylek]

A have taken the bug, I plan to start looking into the static virtual bugs this week. I think I have a similar bug from @MichalStrehovsky but I have yet to figure out whether they're really duplicates or just similar.

[trylek]

I have created a CoreCLR regression test for this and I now understand this a bit better. There are two easy-to-fix bugs around type attribute checks that are the first hit in this case but after that the situation becomes a bit more interesting - namely, the CoreCLR runtime now perceives Test1.M1 as an override of the reabstracted override I2.M1. I'm working on figuring out how to make that transitively land on the primary static virtual.

[trylek]

The CoreCLR fix for the issue has been merged in. For now I am keeping this issue open to track the remaining Mono work.

[lambdageek]

I'm not actually sure there's a Mono issue.

using System;

public interface I1 {
    public static virtual void M1() {
        Console.WriteLine("I1.M1");
    }
}

public interface I2 : I1 {
        static abstract void I1.M1();
}

public interface I3 : I2 {
    static void I1.M1() { Console.WriteLine ("I3.M1"); }
}

public interface I4 : I3 {
        static abstract void I1.M1();
}

public class C : I2 {
    public static void Main() {
        Foo<C>();
    }
    static void Foo<T>() where T : I1
    {
        T.M1();
    }
    static void I1.M1() {
        Console.WriteLine("C.I1.M1");
    }
}

Running this with a .NET 8 preview 1 nightly I get this:

% dotnet run --self-contained -p:UseMonoRuntime=true -r osx-arm64
C.I1.M1

[MichalStrehovsky]

The meaning of this issue is now overloaded. I think Tomas refers to this #80987 (comment).

Maybe we should have closed this issue and opened another one for the issue with different repro steps.

[mangod9]

assume this is ok to close?

[BrzVlad]

Closing since this issue is superseded by #83189 and #67540, which better describe the problem. We still have svm_diamondshape disabled on mono, with this issue in description. To be removed once those other issues are addressed.