Runtime: Representation of function pointer types in the reflection stack

[MichalStrehovsky]

dotnet/csharplang#1951 discusses adding function pointer types to the C# language. The CLR has supported these for a while, but there are areas (such as the reflection stack), where function pointer types are weird/unhandled.

While this will just be a corner area of the C# language, we should probably at least track this:

• [ ] Can we fix ldtoken method explicit instance int32 *(int32) not to return the token of System.IntPtr?
• [ ] Can we use System.Reflection.Pointer to reflection invoke methods that take/return function pointers?
• [ ] Do we need new APIs to inspect/reflection emit function pointer types?

[danmosemsft]

@MichalStrehovsky marked future.

[mjsabby]

Do you know off the top of your head how complicated it is to do the first one?

[MichalStrehovsky]

Do you know off the top of your head how complicated it is to do the first one?

No, I didn't look into it beyond trying that single line and being happy that I didn't have to add any extra work to .NET Native/CoreRT backlog at that time.

[GrabYourPitchforks]

Sample syntax below - here's a method that takes a function pointer of type int -> void as an argument.

public unsafe static void M(delegate*<int, void> ptr) {
}

[GrabYourPitchforks]

We should do this for 5.0 since function pointers support is being added imminently.

[mjsabby]

I hope the "we should do this for 5.0" still applies and we're tracking this as part of the overall function pointers work.

[GrabYourPitchforks]

At the moment it's not currently funded for 5.0 - it's more of a stretch goal. If it's blocking you let us know and we can mark it as such. Then we can pull resources from other things to address it.

[mjsabby]

Yeah this is pretty impactful since I'm wanting to freeze these objects and it is not possible to find which are fnptrs arrays. I'm ok if I can work around it somehow but I don't think I'm able to.

[mjsabby]

@GrabYourPitchforks I see you self-assigned this, does this mean it'll happen in 5.0?!

[GrabYourPitchforks]

Still not funded, but I'm growing increasingly worried that if we don't address it in 5.0 it'll be too difficult to address in 6.0 due to compat. So going to see if we can slam this in at the last minute. It'll definitely be a roller coaster. :)

[ThadHouse]

Now that 5.0 has released, and I'm switching my functions that used to take IntPtr to function pointers, I'm running into this issue.

I have the following interface (simplified of course)

public interface IThing {
    void Function(delegate* unmanaged[Cdecl]<int, void> cb); // This used to be an IntPtr cb
}

I'm generating at runtime using Reflection.Emit an implementation of this interface. However, with function pointers, this does not seem possible. When I iterate the parameters of that function, the parameter just shows up as an IntPtr, with now way to detect its a function pointer. If I generate the function using IntPtr, the signature doesn't match, and the importer fails with a TypeLoadException basically that the interface is not implemented.