Implement Generic support for `UnsafeAccessorAttribute`

[AaronRobinsonMSFT]

Originally defined in #81741, Generic support in UnsafeAccessorAttribute scenarios was not added. This issue tracks that effort across the runtimes.

• CoreCLR - [CoreCLR and native AOT] UnsafeAccessorAttribute supports generic parameters #99468
• NativeAOT - [CoreCLR and native AOT] UnsafeAccessorAttribute supports generic parameters #99468
• Mono - [mono] Implement generic support for UnsafeAccessorAttribute #99830
• Update official documentation for UnsafeAccessorAttribute - Add examples for generic support. dotnet-api-docs#9746

For bound generic parameters this was originally thought to work but was broken after the final signature validation logic was implemented. This was reported in #92633 as a regression. That issue has been subsequently closed and folded into this work to support Generics on bound parameters too.

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<string> StringField(MyClass<string> _this);

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<double> DoubleField(MyClass<double> _this);

Example with unbound generic parameters.

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<T> Field<T>(MyClass<T> _this);

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Originally defined in #81741, Generic support in UnsafeAccessorAttribute scenarios was not added. This issue tracks that effort across the runtimes.

• CoreCLR
• NativeAOT
• Mono

We are waiting to see community need for this work so setting to Future.

Author:	AaronRobinsonMSFT
Assignees:	-
Labels:	area-System.Runtime.CompilerServices
Milestone:	Future

[AaronRobinsonMSFT]

@lambdageek @MichalStrehovsky @jkotas @fanyang-mono This issue is being used to track Generic support going forward.

[MichalPetryka]

This would be really useful when working with generic code for example in Serialization scenarios. Without this a lot of things still require DynamicMethod.

[lambdageek]

Is it worth clarifying that specific generic instances, work already. So if we have MyClass<T> that has a private List<T> _myList member, then you can define, for example

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<string> StringField(MyClass<string> @this);

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<double> DoubleField(MyClass<double> @this);

just not the fully generic

[UnsafeAccessor(UnsafeAccessorKind.Field, Name="_myList")]
static extern ref List<T> Field<T>(MyClass<T> @this);

[AaronRobinsonMSFT]

Is it worth clarifying that specific generic instances, work already. So if we have MyClass<T> that has a private List<T> _myList member, then you can define

Agreed. I've updated the title to state "unbound" generics. Will move your examples up to the main area.

[neon-sunset]

Just to express support for the feature, writing an efficient dictionary implementation that inherits from Dictionary<SomeUtf8StringImplementation, V> and allows using ReadOnlySpan<byte> for lookup is impossible without support for generics. Yes, this is a hack that has to rely on extensive test coverage to guard against a case where dictionary internals change, but there is no other option until type system accommodates for this in a bright but distant future.

[Kira-NT]

Just discovered that generic support hasn't been implemented yet (and, as it currently seems, won't be implemented until .NET 9) during the unit-testing stage of my library, and thank god I did :)

This feature is definitely needed. In fact, I'd argue that it's somewhat counter-intuitive that it isn't functional yet. This is especially so given that it was mentioned in the original proposal, and that the general principle - "copy-paste the original signature, add the target type as the first parameter, and you're good to go" - fails in this instance without any compiler warning (I hope it does for NAOT, though I haven't tested it yet).

In my specific situation, I attempted to access Enum.TryFormatUnconstrained<TEnum>(TEnum value, Span<char> destination, out int charsWritten, ReadOnlySpan<char> format), an internal version of Enum.TryFormat without generic constraints (where TEnum : struct, Enum). Unfortunately, despite the remarkable efforts from Stephen Toub in #78580, it's still impossible to utilize the optimal way of formatting enum values in an arbitrary generic method defined as Foo<T>(). This remains the case even if you've conducted a check yourself using typeof(T).IsEnum, as generic constraints remain unaware of it.

My problem here can be broken down into two components:

1. The inability to apply the UnsafeAccessorAttribute to a generic method.
2. The inability to invoke a method with generic constraints that represent a superset of the current method's generic constraints, even if I've conducted all the necessary checks myself.

There's a suggestion to establish a "bridging" system for generic constraints (dotnet/csharplang#6308) that might address (2). However, since it's proposed as a language feature, and the consensus on its design is yet to be found, it may take another 5 or 10 years to implement. So, why not consider it as a runtime feature instead, while simultaneously addressing (1)?

The original proposal states:

The generic constraints of the extern static method must match generic constraints of the target type, field or method.

I suggest either entirely disregarding this section or, preferably, introducing a mechanism to deliberately opt out of this verification. For instance, in my scenario, if I wish to call Enum.TryFormat with an arbitrary generic argument, I could create an accessor that permits me to bypass the constraints:

[UnsafeAccessorIgnoreGenericConstraints]
[UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = nameof(Enum.TryFormat))]
static extern bool TryFormat<TEnum>(Enum? targetType, TEnum value, Span<char> destination, out int charsWritten, ReadOnlySpan<char> format);

To be quite frankly honest with you, this approach seems so much better compared to relying on the existence of an internal helper method, as such methods can be moved, renamed, or deleted in any non-breaking .NET update, as they aren't part of the public API.

If the final implementation of unsafe accessors evolves in this direction, it would be fantastic, as it simultaneously addresses:

1. The suppression of visibility checks.
2. The suppression of generic constraint checks.

At the end of the day, they are unsafe accessors, so incorporating this feature seems to fit seamlessly within their purview. In any case, I'm eager to hear others' opinions on this topic! :)