Unexpected metadata for function signature when defined as member vs local

[AaronRobinsonMSFT]

The following definitions of the same signature result in surprising different metadata.

static class Accessors
{
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "<obj>P")]
    public static extern ref readonly object MEMBER(ref readonly Foo value); 
    
    public static void A()
    {
        [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "<obj>P")]
        static extern ref readonly object LOCAL(ref readonly Foo value);
    }
}

SharpLab

For MEMBER:

    .method public hidebysig static 
        object& modreq([System.Runtime]System.Runtime.InteropServices.InAttribute) MEMBER (
            [in] valuetype Foo& 'value'
        ) cil managed 

For LOCAL:

    .method assembly hidebysig static 
        object& '<A>g__LOCAL|1_0' (
            [in] valuetype Foo& 'value'
        ) cil managed 

The primary surprise is lack of the modreq on the LOCAL signature. This confusion led to the writing of a test that "validated" nothing, because there was no modreq. This difference is now understood and the runtime team will make sure tests are written to respect this fact, but it does seem odd the exact signature will yield different signatures when there are cases the runtime cares about custom modifiers.

See dotnet/runtime#111647 for the issue.

/cc @jaredpar @AlekseyTs

[jaredpar]

The motivation for using a modreq on a ref readonly is reducing the change another compiler would use such a method and inadvertently treat it as ref thus violating readonly semantics. That means it's only useful on methods which are accessible to other languages. A local function is not generally considered accessible because it's generated as unspeakable names.

At the same time though, I'm unsure if this was a deliberate decision on our part or accident of implementation. If it's an accident then I'd be fine with a fix. Possible this was just an oversite when we did the feature.