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);

[ghost]

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.

[Kir-Antipov]

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! :)

[MichalPetryka]

I suggest either entirely disregarding this section or, preferably, introducing a mechanism to deliberately opt out of this verification.

I feel like adding such support would be useful in some cases, the runtime would just throw when the T doesn't meet the constraints, not when the constraints don't match.

[En3Tho]

F# has a feature of generic state machine builders. It's a feature that empowers you to write all sorts of stuff like specialized Tasks, AsyncEnumerables, custom Coroutines, all sorts of iterators using a unified approach.

These generally relay on template type that has among others has a Data field with user defined data like for example T Result field to store a return value. When expanded, F# first generate fields for state machine captures/closures before Data so getting Data field from resulting generated type is tricky and requires either knowing an offset (by invoking reflection) or resorting to other hacks.

It would be really nice to have an UnsafeAccessor that could just get Data field from any generated state machine.

Just wanted to share a use case for this.

[Sergio0694]

We could also use this in CsWinRT (here), so we could go from this:

private static Func<T, IObjectReference> BindToAbi()
{
    var objField = HelperType.GetField("_obj", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly);
    return (T arg) => (IObjectReference) objField.GetValue(arg);
}

To this:

private static Func<T, IObjectReference> BindToAbi()
{
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name="_obj")]
    static extern ref IObjectReference GetObj(T _this);

    return (T arg) => GetObj(arg);
}

Or actually just skip the function entirely and just call GetObj directly when needed, no caching necessary anymore.

[AaronRobinsonMSFT]

    [UnsafeAccessor(UnsafeAccessorKind.Field, Name="_obj")]
    static extern ref IObjectReference GetObj(T _this);

Field access in this manner on reference types won't work with shared generics, there are no fields on Canon to acquire.

[roald-di]

Is there some information available on which scenarios are going to be supported?

I'm mostly interested in whether it is going to be possible to define an accessor in a generic class and if generic methods are going to work.

At the moment both of these examples result in 'Invalid usage of UnsafeAccessorAttribute'.

// note no generics are used in the accessor itself
public class Accessors<T>
{
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "value")]
    public static extern ref int GetValue(MyClass _this);
}

[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "Method")]
public static extern T Method<T>(MyClass _this);

If the answer to the above is yes, is a more complicated example like the following going to work?

public class Outer<TOuter>
{
    public class Inner<TInner>
    {
        Tuple<TOuter, TInner, T>? Method<T>() => null;
    }
}

public class Accessors<TOuter, TInner>
{
    [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "Method")]
    public static extern Tuple<TOuter, TInner, T> Method<T>(Outer<TOuter>.Inner<TInner> _this);
}

or at least this?

public class Accessors
{
    [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "Method")]
    public static extern Tuple<TOuter, TInner, T> Method<TOuter, TInner, T>(Outer<TOuter>.Inner<TInner> _this);
}

[alrz]

Since static members don't need an instance, could this accept a System.Type instead?

    [UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = "get_Descriptor")]
    public extern static MessageDescriptor GetDescriptor(System.Type type);

[AaronRobinsonMSFT]

Since static members don't need an instance, could this accept a System.Type instead?

    [UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = "get_Descriptor")]
    public extern static MessageDescriptor GetDescriptor(System.Type type);

No. The design requires the type to be explicit. As mentioned though, since the target member is static a value of null can be passed.

Using Type would make things difficult since it would require inspection at each dispatch to determine the target. Requiring the type explicitly in the signature enables zero overhead after the method is jitted. This would not be the case if System.Type were used.

[ajphall]

Hi,

Did these changes make it into 9.0.100-preview.3.24204.13?

I am trying for example to do this:

public static class SortedListAccessor<TKey, TValue> where TKey : notnull
{
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "keys")]
    public static extern ref TKey[] GetKeys(SortedList<TKey, TValue> list);
}

var l = new SortedList<string, string>();
var keys = SortedListAccessor<string, string>.GetKeys(l);

But I get a System.BadImageFormatException: 'Invalid usage of UnsafeAccessorAttribute.'

[reflectronic]

No, it'll be available in Preview 4