Mono's behavior around .beforefieldinit

[EgorBo]

The following program:

using System;
using System.Runtime.CompilerServices;

C.TestMethod(false);
Console.WriteLine("Done");

static class C
{
    [MethodImpl(MethodImplOptions.NoInlining)] // doesn't matter, but JIC
    public static int TestMethod(bool cond)
    {
        if (cond)
        {
            // never invoked in this program
            return ClassB.X;
        }
        // always taken
        return 0;
    }
}

public class ClassB
{
    public static readonly int X = GetX();

    static int GetX()
    {
        Console.WriteLine("GetX call!"); // not expected to be invoked in this program
        return 42;
    }
}

Output on Mono:

GetX call!
Done

Output on CoreCLR:

Done

It's not wrong according to ECMA-335:

: BeforeFieldInit behavior is intended for initialization code with no interesting sideeffects, 
where exact timing does not matter. Also, under BeforeFieldInit semantics, type
initializers are allowed to be executed at or before first access to any static field of that type,
at the discretion of the CLI.

However, it'd be nice to align this behavior with CoreCLR to avoid potential issues like the one I've hit in #77398 (comment). And, obviously, in this case Mono executed completely redundant code (did more work). I think I've hit the same issue in the past where static initialization in Mono triggered DllImport leading to DllNotFoundException while CoreCLR didn't, can't find the issue.

Related issue: #4346 (see #4346 (comment))

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[SamMonoRT]

@LeVladIonescu - please investigate this.

[SamMonoRT]

@lambdageek - PR is up, but still encountering some CI failures. Moving this to 9.0.0

[lambdageek]

@SamMonoRT please add postponed issues to the burndown project and set a priority - otherwise these issues just get left behind and we don't act on them for 11 months and then postpone them again.

[lambdageek]

We should revive #86787 early in .NET 10. static cctor order changes are hard to diagnose and this late in the net9 release it feels risky