NativeAOT: Dependency analysis support for generic method reflection

[hez2010]

I hope ILCompiler dependency analysis can take generic pattern into account so that we don't need rd.xml for this case any longer:

// Here we have System.Array.IndexOf<System.Int32>(System.Int32[],System.Int32)
var method = typeof(Array).GetTypeInfo().GetMethod(nameof(Array.IndexOf), 1, BindingFlags.Public | BindingFlags.Static | BindingFlags.DeclaredOnly, null, CallingConventions.Any, new[] { Type.MakeGenericMethodParameter(0).MakeArrayType(), Type.MakeGenericMethodParameter(0) }, null)!.MakeGenericMethod(typeof(int));
var array = new int[] { 3, 2, 1, 0 };
Console.WriteLine(method.Invoke(null, new object?[] { array, 0 }));

Current behavior without a rd.xml:

Unhandled Exception: EETypeRva:0x00306AF8(System.Reflection.MissingRuntimeArtifactException): MakeGenericMethod() cannot create this generic method instantiation because no code was generated for it: 'System.Array.IndexOf<System.Int32>(System.Int32[],System.Int32)'.

[jkotas]

cc @MichalStrehovsky

[MichalStrehovsky]

It could but we haven't put the effort into it because I didn't think this pattern would be common. We would need to know the exact method and the exact instantiation arguments. Whenever I see this pattern, the instantiation arguments are usually statically unknown.

If everything is statically known, one is usually better off e.g. constructing a delegate.

Do you have a real world example of this?

[hez2010]

efcore is using this pattern heavily to get generic method.

[MichalStrehovsky]

Do you have an example? I did a quick search for MakeGenericMethod.*typeof regex but I haven't seen a spot that would look like this. We either don't know the left hand side (the method... for reasons such as reading it from a field, or using LINQ (!!!) to find the interesting method), or we don't know the right hand side (the arguments).

[hez2010]

An example: https://github.com/npgsql/efcore.pg/pull/2028/files#r725139551
I added a comment there to suggest replacing LINQs with pure reflection APIs.

[MichalStrehovsky]

That one doesn't seem to be calling MakeGenericMethod though.

In general if the exact generic method is known, it's probably more efficient to get a delegate to it and if one really needs a MethodInfo, call Delegate.GetMethodInfo. I wish C# had a methodof.

[JamesNK]

Example of where this would be useful:

internal static class ResultsOfTHelper
{
    [UnconditionalSuppressMessage("AOT", "IL3050", Justification = "MakeGenericType is safe because the target can be statically analyzed during compile.")]
    public static void PopulateMetadataIfTargetIsIEndpointMetadataProvider<TTarget>(MethodInfo method, EndpointBuilder builder)
    {
        if (typeof(IEndpointMetadataProvider).IsAssignableFrom(typeof(TTarget)))
        {
            var methodInfo = typeof(MetadataPopulator<>).MakeGenericType(typeof(TTarget)).GetMethod("PopulateMetadata")!;
            methodInfo.Invoke(null, new object[] { method, builder });
        }
    }

    internal static class MetadataPopulator<TTarget> where TTarget : IEndpointMetadataProvider
    {
        public static void PopulateMetadata(MethodInfo method, EndpointBuilder builder)
        {
            TTarget.PopulateMetadata(method, builder);
        }
    }
}

It currently fails when TTarget is a value type.

ASP.NET Core issue to use future improvement: dotnet/aspnetcore#46267

[hez2010]

@MichalStrehovsky Even everything is statically known, we may still have to use MakeGenericType/MakeGenericMethod due to some generic constraints cannot be satisfied at the compile time but only at the runtime.
The current C# lacks the ability of pattern matching on generic parameters/generic method overloads on constraints, see dotnet/csharplang#6308.

[MichalStrehovsky]

Yup, that's why I brought this over from runtimelab. The linked discussion in the aspnetcore repo is about bridging constraints

[MichalStrehovsky]

We don't have a good spot to do this in the compiler. Dataflow analysis runs on top of uninstantiated IL so we can't do this there.

This would ideally be done in RyuJIT (intrinsic expansion of typeof(Foo<>).MakeGenericType(typeof(T)) to typeof(Foo<T>), provided constraints are met, etc). If we do it in RyuJIT, we also need to do it in IL Scanner.

Another closest spot where we could do this is the constant propagation (that rewrites IL) - this would be a single spot on the managed compiler side and it would not require RyuJIT work. However, we don't have facilities to easily do it here. The result would not be great.

I'm moving this to 9.0. This would be better done if we lay some foundational groundwork first.