[release/9.0-staging] UnsafeAccessor - ambiguous name and signature match

[AaronRobinsonMSFT]

Backport of #119972 to release/9.0-staging

/cc @AaronRobinsonMSFT

Customer Impact

• Customer reported
• Found internally

The UnsafeAccessorAttribute doesn't properly differentiate ambiguity for between the two signatures below. Both are void(*)(void) and in that case the generic calling convention isn't used to indicate distinct signatures.

class C
{
    private static void M() { }
    private static void M<T>() { }
}

Customer reported in #119875.

Regression

• Yes
• No

This is regression from .NET 8 because we didn't support generics method with UnsafeAccessorAttribute. When it was added in .NET 9, a test case was missed. A new test was added to validate this scenario.

Testing

A test was added.

Risk

Low.

[Copilot]

Pull Request Overview

This PR fixes an issue with UnsafeAccessor where it couldn't properly differentiate between ambiguous method signatures that have the same calling convention but different generic parameter counts. The fix ensures that both generic and non-generic methods with the same name can be properly distinguished.

Key changes:

• Added proper generic parameter count validation in signature matching
• Enhanced test coverage to verify ambiguous method name resolution with generics
• Updated existing test cases to use more descriptive naming

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/tests/baseservices/compilerservices/UnsafeAccessors/UnsafeAccessorsTests.Generics.cs	Added comprehensive test cases for ambiguous method names and updated existing tests with clearer naming
src/coreclr/vm/prestub.cpp	Fixed signature matching logic to properly handle generic calling conventions and parameter counts
src/coreclr/tools/Common/TypeSystem/IL/UnsafeAccessors.cs	Added generic parameter count validation in method signature matching

[dotnet-policy-service]

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

[jkotas]

This fix will make the following code throw MissingMethodException instead of InvalidProgramException. Is that correct?

using System.Runtime.CompilerServices;

class Program
{
    static void Main()
    {
        // Throws System.Reflection.AmbiguousMatchException: 'Ambiguity in binding of UnsafeAccessorAttribute.'
        Example(null);
    }

    [UnsafeAccessor(UnsafeAccessorKind.StaticMethod)]
    private static extern void Example(ContainingClass? _);
}

class ContainingClass
{
    private static void Example<T>() { }
}

I am not sure whether it meets the servicing bar. If there is a code out there that implemented a workaround for this corner-case bug by catching InvalidProgramException, it is going to break.

[AaronRobinsonMSFT]

This fix will make the following code throw MissingMethodException instead of InvalidProgramException. Is that correct?

I think this is fine and the correct exception in this case.

[AaronRobinsonMSFT]

/ba-g timeouts