.NET 8 and static BLOB pattern using ROS<T>

[sakno]

Starting from .NET 8, it's possible to use pattern like this:

private static ReadOnlySpan<int> Integers => [10, 20, 30];

which is compiled to

ldtoken field valuetype '<PrivateImplementationDetails>'/'__StaticArrayInitTypeSize=12_Align=4' '<PrivateImplementationDetails>'::'97CA1592048640A5368B4EC7C6934311567E09D50E7639918EC82C3D2A187CDA4'
call valuetype [System.Runtime]System.ReadOnlySpan`1<!!0> [System.Runtime]System.Runtime.CompilerServices.RuntimeHelpers::CreateSpan<int32>(valuetype [System.Runtime]System.RuntimeFieldHandle)
ret

.class private auto ansi sealed '<PrivateImplementationDetails>'
    extends [System.Runtime]System.Object
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (
        01 00 00 00
    )
    // Nested Types
    .class nested private explicit ansi sealed '__StaticArrayInitTypeSize=12_Align=4'
        extends [System.Runtime]System.ValueType
    {
        .pack 4
        .size 12

    } // end of class __StaticArrayInitTypeSize=12_Align=4


    // Fields
    .field assembly static initonly valuetype '<PrivateImplementationDetails>'/'__StaticArrayInitTypeSize=12_Align=4' '97CA1592048640A5368B4EC7C6934311567E09D50E7639918EC82C3D2A187CDA4' at I_000027F0
    .data cil I_000027F0 = bytearray (
        0a 00 00 00 14 00 00 00 1e 00 00 00
    )

}

Previously, it was allowed for ROS<byte> only. There was a bug in Cecil library: dotnet/cecil#61 that leads to the following exception:

System.ArgumentException : Value does not fall within the expected range.
  Stack Trace:
     at System.Runtime.CompilerServices.RuntimeHelpers.GetSpanDataFrom(RuntimeFieldHandle fldHandle, RuntimeTypeHandle targetTypeHandle, Int32& count)
   at System.Runtime.CompilerServices.RuntimeHelpers.CreateSpan[T](RuntimeFieldHandle fldHandle)

In my case, this exception is always reproducible. I think it happens because InlineIL uses outdated Cecil library. I'm not sure for 100% but it's a main suspicion. Could you release a new InlineIL with updated Fody and Cecil dependencies? Latest Fody version uses updated Cecil (6.8.0).

[ltrzesniewski]

Hi, InlineIL uses the Cecil from Fody, which uses https://github.com/jbevain/cecil (with a few patches on its own), not https://github.com/dotnet/cecil.

They usually backport fixes like this to https://github.com/jbevain/cecil, and this has been done there: jbevain/cecil#888.

But Fody actually uses its own Cecil from https://github.com/Fody/cecil, and the latest release https://github.com/Fody/Fody/releases/tag/6.8.0 updates Cecil as you say. So we get the following dependency "stack" in the end:

• https://github.com/Fody/cecil
• https://github.com/jbevain/cecil
• https://github.com/dotnet/cecil

So I'm not sure what you're asking for here. Are you saying that InlineIL 1.7.4 causes the exception when used with Fody 6.8.0, or are you asking me to release an updated InlineIL version which depends on Fody 6.8.0?

Everything should work fine if you use InlineIL 1.7.4 with Fody 6.8.0. If you can confirm that, I can release an update which depends on Fody 6.8.0 so that the latest version of Cecil is used by default.

[sakno]

I think the issue can be closed. The root cause is Code Coverage instrumentation from .NET Test Sdk which uses outdated Cecil.

[ltrzesniewski]

Ok, but since you got this issue I guess I should update InlineIL anyway to use Fody 6.8.0 by default.

[ltrzesniewski]

I've released v1.8.0