Potential bug in byref-like generics (allows ref struct)

[GeeLaw]

The runtime does not permit TypedReference as a generic argument, but the other two "old" byref-like types (ArgIterator and RuntimeArgumentHandle) are allowed.

// Windows 11 version 24H2 x64 .NET 10.0.
using System;

static class Program
{
  private ref struct Wrapper<T> where T : allows ref struct
  {
  }
  public static void M<T>() where T : allows ref struct
  {
  }
  static void CreateType(Type t)
  {
    try
    {
      typeof(Wrapper<>).MakeGenericType(t);
      Console.WriteLine("CreateType succeeded.");
    }
    catch (Exception ex)
    {
      Console.WriteLine("CreateType failed: " + ex.GetType());
    }
  }
  static void CreateMethod(Type t)
  {
    try
    {
      typeof(Program).GetMethod(nameof(M)).MakeGenericMethod(t);
      Console.WriteLine("CreateMethod succeeded.");
    }
    catch (Exception ex)
    {
      Console.WriteLine("CreateMethod failed: " + ex.GetType());
    }
  }
  static void Main()
  {
    foreach (var t in new[] { typeof(ArgIterator), typeof(RuntimeArgumentHandle), typeof(TypedReference) })
    {
      Console.WriteLine(t);
      CreateType(t);
      CreateMethod(t);
      // For TypedReference, we get TypeLoadException and BadImageFormatException.
    }
  }
}

In Ecma-335-Augments.md:

• "ByRefLike types in generics" does not prevent TypedReference from being used as a generic argument.
• "Ref Fields" states "converting TypedReference [...] into following the normal rules of C# ref structs is desired."
• "Ref Fields" has

Replace “Typed references have the same restrictions as byrefs.” With “Typed references are byref-like types and have the same restrictions as normal byref-like types.”

All of those suggest that TypedReference should be usable as a generic type argument.

[huoyaoyuan]

The design doc also mentions Span<TypedReference> as an example. Is it the intention to make TypedReference a "regular" ref struct in all cases?

The current C# compiler doesn't allow TypedReference to be used in allows ref struct. MSVC seems to not verify ref struct at all.

@jkotas This may need to get different teams involved. Can you help for this?

[jkotas]

The current C# compiler doesn't allow TypedReference to be used in allows ref struct.

Right, this part of the ref fields feature was postponed. We have done some of the work towards it in the runtime, so runtime and C# are inconsistent currently. See:

https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/low-level-struct-improvements.md#sunset-restricted-types
dotnet/roslyn#64811
#26186

[GeeLaw]

S<TR>is surprising to me because S<T> has a constructor with T[] parameter, which would prevent ref struct TR from being used (until generics semantics is enhanced/relaxed to remove unusable methods automatically).

Digress: S<ref struct> is essentially an unmanaged pointer plus a length, because ref struct can only live the call stack — the call stack is not movable as documented by ldloca.

[GeeLaw]

The current C# compiler allows none of the "old" byref-like types in allows ref struct (nor returns, fields), not just TR… (The runtime is more accepting than C#.)

[jkotas]

I have opened #123626 to amend the documentation to better document the current state. If you would like to see more edits in the ecma augments doc to make this clear, please comment on the PR.

The design doc also mentions Span as an example

Where do you see this mentioned in the design doc?

[huoyaoyuan]

The design doc also mentions Span as an example

Where do you see this mentioned in the design doc?

It's mentioned here:

runtime/docs/design/features/byreflike-generics.md

Lines 5 to 6 in 861226a

	- `Span<TypedReference>` &ndash; Represents the general case where a ByRefLike type is used as a Generic parameter. This specific case would be desirable for a more efficient Reflection API.
	- `Span<Span<char>>` &ndash; Nested `Span<T>` types would be of benefit in the parsing result of strings.

Of course it's simply for demonstration since Span isn't employing allows ref struct currently. It's spirit should be allowing TR too.

[jkotas]

Fixing that in #123626 (comment) . Span<Span<char>> and similar constructs are complicated problem for escape analysis.

[josephmoresena]

I’m facing a similar issue with my custom pointer types in Rxmxnx.PInvoke.Extensions (ValPtr<T>, ReadOnlyValPtr<T>). At the moment, I have to generate IL code for incompatible methods to work around this limitation, in order to avoid breaking binary compatibility with .NET 8.0 and earlier versions.

My decision to allow ValPtr<T> and ReadOnlyValPtr<T> to accept ref struct types is based on the fact that it is perfectly valid to have a managed reference to a ref struct. However, the problem arises because these types can, at certain points, be used to create Span<T>, which breaks the rules.

So far, my testing shows that this IL patching approach works correctly in both JIT and AOT scenarios, but it would be great to have a proper language-level alternative instead.