System.Reflection.MetadataLoadContext doesn't support function pointer types

[vargaz]

To reproduce: run the attached project
Version: master
Expected result: works
Actual result:

Unhandled exception. System.NotSupportedException: Parsing function pointer types in signatures is not supported.
   at System.Reflection.TypeLoading.Ecma.EcmaModule.GetFunctionPointerType(MethodSignature`1 signature)
   at System.Reflection.Metadata.Ecma335.SignatureDecoder`2.DecodeType(BlobReader& blobReader, Boolean allowTypeSpecifications, Int32 typeCode)
   at System.Reflection.Metadata.Ecma335.SignatureDecoder`2.DecodeMethodSignature(BlobReader& blobReader)
   at System.Reflection.TypeLoading.Ecma.EcmaMethodDecoder.SpecializeMethodSig(IRoMethodBase roMethodBase)
   at System.Reflection.TypeLoading.RoDefinitionMethod`1.ComputeMethodSig()
   at System.Reflection.TypeLoading.RoMethod.get_MethodSig()
   at System.Reflection.TypeLoading.RoMethod.get_ReturnParameter()
   at System.Reflection.TypeLoading.RoMethod.get_ReturnType()

[vargaz]

test.tar.gz

[marek-safar]

Hmm how is Roslyn reading such metadata?

@jaredpar @MichalStrehovsky

[MichalStrehovsky]

This looks like a bug in System.Reflection.MetadataLoadContext. It's a library built on top of System.Reflection.Metadata that provides additional abstractions over the metadata. Roslyn only uses S.R.Metadata, not this extra layer with the missing implementation.

[steveharter]

This looks like a bug in System.Reflection.MetadataLoadContext

It is apparently by design since it throws an explicit NotSupportedException when detecting a function pointer.

This overlaps with #11354 where we don't return function pointer type from standard reflection either and need a way to represent that.

Doing a typeof(delegate*<void>) (for example) returns System.IntPtr as the type, so it would be expected that MLC return IntPtr as the type. However, that doesn't allow inspection of the parameters or return type, and there is not an existing "function pointer" type in .NET that we can readily use instead.

[steveharter]

@vargaz @CoffeeFlux can you add more detail including the workaround you use, and the "blocking" label if you consider it blocking. Thanks

[vargaz]

We just hardcode the method names which have these types in our code, it's not currently a blocker for us.

[lewing]

@steveharter the current workaround is here

runtime/tools-local/tasks/mobile.tasks/WasmAppBuilder/PInvokeTableGenerator.cs

Line 156 in 8692967

if (method.Name == "EnumCalendarInfo") {

[jeromelaban]

This is a feature that will be a important addition for libraries like SkiaSharp running on WebAssembly.

[lewing]

Yes it will be required for #44636 if we continue to use MLC

[lewing]

This will be an ongoing issue for blazor/webassembly.

[marek-safar]

@krwq why was it moved to 7.0 when #43791 (comment) explained that this is needed for P1 .NET user story?

[MichalStrehovsky]

My 5 cents: I'm not sure this can be implemented in MetadataLoadContext without first defining how function pointers are supposed to look like within the runtime/reflection stack (#11354 tracks parts of that), like @steveharter pointed out.

Function pointer behavior is currently pretty arbitrary within the runtime reflection stack: https://twitter.com/MStrehovsky/status/1311247635756412928

I don't know if it's good use of time to make MetadataLoadContext emulate that behavior only so that we can break it again when #11354 is defined just because a tool took a dependency on it.

I would suggest looking into a technology that is more suitable to build compiler components - System.Reflection.Metadata directly, or even Cecil.

[vargaz]

Maybe we can fix our wasm tooling to work around this, but function pointer types are increasing in usage, so other users will run into this problem.

[krwq]

@marek-safar we've moved most of the issues marked as enhancement to 7.0.0/Future - must've missed the comment. Should this issue have arch-wasm - this way it will disappear from our radar?

[lambdageek]

@steveharter Will the #69273 MetadataLoadContext work also happen in 7? Will that include also the .NET Framework version of MLC? If so, that will help us with this issue with the wasm tooling.

[steveharter]

@lambdageek yes MetadataLoadContext will be updated along with the CoreClr runtime. The active PR is #71516.

It should be possible to use .NET framework with MetadataLoadContext function pointers although reflection will necessary to call the new APIs on Type. I'll provide an example once that PR is in.

[jkotas]

It should be possible to use .NET framework with MetadataLoadContext function pointers although reflection will necessary to call the new APIs on Type. I'll provide an example once that PR is in.

We may want to provide extension methods so that it is not necessary to use reflection.

[steveharter]

Moving to 8.0; we need to update the API and design based on feedback from #71516.