Support function pointer types in System.Reflection.Emit

[jgh07]

This fixes #111003. The current implementation is a work in progress, only managed function pointers with no modopts are supported.

I imagine adding support for unmanaged calling conventions and custom modifiers will be a bit more challenging, since I cannot use Type.GetFunctionPointerCallingConventions et al.

[dotnet-policy-service]

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

[jgh07]

@jgh07 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@dotnet-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@dotnet-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@dotnet-policy-service agree company="Microsoft"

Contributor License Agreement

@dotnet-policy-service agree

[jgh07]

I've now added support for unmanaged calling conventions and custom modifiers, altough there are still some limitations which I outlined in the original issue (#111003).

Fully supporting all possible variants of function pointer types will require updates of the reflection API, as far as I'm concerned. Still, my implementation should support everything that C# currently supports, which is why I am opening the PR for review.

I understand if this PR cannot be merged until there is comprehensive support for the feature, altough in my opinion it is already 90% of the way there in terms of support for real-life scenarios.

[Copilot]

Pull Request Overview

This PR adds support for function pointer types in System.Reflection.Emit by implementing signature generation for function pointers. The implementation currently supports managed function pointers without custom modifiers (modopt), with unmanaged calling conventions and custom modifiers planned for future work.

Key changes:

• Added function pointer type detection and handling in signature generation
• Implemented calling convention mapping for function pointers
• Added support for custom modifiers on function pointer return types and parameters

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[jkotas]

Could you please add tests as well?

[jgh07]

Could you please add tests as well?

Done.

[jkotas]

PersistedAssemblyBuilder should not assume that the types are from the runtime reflection type universe. This should match the types by name to handle any type universes.

Here is an example of prior art:

runtime/src/libraries/System.Reflection.Emit/src/System/Reflection/Emit/TypeBuilderImpl.cs

Lines 460 to 485 in 457c6b7

	protected override void SetCustomAttributeCore(ConstructorInfo con, ReadOnlySpan<byte> binaryAttribute)
	{
	// Handle pseudo custom attributes
	switch (con.ReflectedType!.FullName)
	{
	case "System.Runtime.InteropServices.StructLayoutAttribute":
	ParseStructLayoutAttribute(con, binaryAttribute);
	return;
	case "System.Runtime.CompilerServices.SpecialNameAttribute":
	_attributes |= TypeAttributes.SpecialName;
	return;
	case "System.SerializableAttribute":
	#pragma warning disable SYSLIB0050 // 'TypeAttributes.Serializable' is obsolete: 'Formatter-based serialization is obsolete and should not be used'.
	_attributes |= TypeAttributes.Serializable;
	#pragma warning restore SYSLIB0050
	return;
	case "System.Runtime.InteropServices.ComImportAttribute":
	_attributes |= TypeAttributes.Import;
	return;
	case "System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeImportAttribute":
	_attributes |= TypeAttributes.WindowsRuntime;
	return;
	case "System.Security.SuppressUnmanagedCodeSecurityAttribute": // It says has no effect in .NET Core, maybe remove?
	_attributes |= TypeAttributes.HasSecurity;
	break;
	}

[jkotas]

Would it be useful to have tests that validate one assembly can reference function pointer field in other assembly?

[jgh07]

Good idea. I modified my repro from the original issue and added it as a test.

[jkotas]

The new test is failing:

   System.Reflection.Emit.Tests.AssemblySaveTypeBuilderTests.ConsumeFunctionPointerFields [FAIL]
      System.IO.FileNotFoundException : Could not load file or assembly 'Assembly1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
      
      Stack Trace:
           at Program.Main()
           at System.RuntimeMethodHandle.InvokeMethod(ObjectHandleOnStack target, Void** arguments, ObjectHandleOnStack sig, BOOL isConstructor, ObjectHandleOnStack result)
           at System.RuntimeMethodHandle.InvokeMethod(ObjectHandleOnStack target, Void** arguments, ObjectHandleOnStack sig, BOOL isConstructor, ObjectHandleOnStack result)

[jkotas]

This should use TestAssemblyLoadContext, similar to

runtime/src/libraries/System.Reflection.Emit/tests/PersistedAssemblyBuilder/AssemblySaveILGeneratorTests.cs

Lines 2962 to 2964 in 8f0e8ab

	TestAssemblyLoadContext tlc = new TestAssemblyLoadContext();
	tlc.LoadFromAssemblyPath(file.Path);
	Type typeFromDisk = tlc.LoadFromAssemblyPath(file2.Path).GetType("Type2");

[jgh07]

Addressed in the newest commit.
Hope the test runs now, it worked on my machine™.