Microsoft.Dotnet.Compatibility analyzer doesn't work with the NumericIntPtr feature

https://github.com/dotnet/runtime/pull/69627 updated the dotnet/runtime repo to utilize the NumericIntPtr feature from C# 11: https://github.com/dotnet/csharplang/issues/6065

This resulted in the compatibility analyzer misfiring with many errors such as:

/__w/1/s/.packages/microsoft.dotnet.compatibility/2.0.0-alpha.1.21525.11/build/Microsoft.NET.Compatibility.Common.targets(33,5): error CP0002: Member 'Microsoft.Extensions.Caching.Memory.PostEvictionDelegate.PostEvictionDelegate(object, System.IntPtr)' exists on lib/net6.0/Microsoft.Extensions.Caching.Abstractions.dll but not on lib/net7.0/Microsoft.Extensions.Caching.Abstractions.dll [/__w/1/s/src/libraries/Microsoft.Extensions.Caching.Abstractions/src/Microsoft.Extensions.Caching.Abstractions.csproj]
##[error].packages/microsoft.dotnet.compatibility/2.0.0-alpha.1.21525.11/build/Microsoft.NET.Compatibility.Common.targets(33,5): error CP0002: (NETCORE_ENGINEERING_TELEMETRY=Build) Member 'Microsoft.Extensions.Caching.Memory.PostEvictionDelegate.PostEvictionDelegate(object, System.IntPtr)' exists on lib/net6.0/Microsoft.Extensions.Caching.Abstractions.dll but not on lib/net7.0/Microsoft.Extensions.Caching.Abstractions.dll

This is despite the underlying assemblies still containing the correct signatures. I noticed the version was out of date and so grabbed the latest package available, 2.0.0-preview.4.22252.4, to see the same error.

[cston]

If RuntimeFeatures.NumericIntPtr is not found, it looks like the compiler will treat a type reference to System.IntPtr as System.IntPtr unless there is an associated [NativeInteger] attribute.

[tannergooding]

IntPtr and nint are identical types to the runtime and always have been, even when targeting .NET Framework or .NET Standard. The C# compiler has never emitted any modreq or modopt differentiating them, only the [NativeInteger] attribute.

Other languages will just see IntPtr. C# itself likewise maintained an identity conversion between its own concept of IntPtr and nint, which means that IntPtr[] and nint[] are interchangeable. As are ref IntPtr with ref nint and out IntPtr with out nint, etc.

The only real difference is the members exposed by each. Prior to .NET 7, IntPtr exposed exactly the members declared by the BCL in System.IntPtr. While nint hid a couple properties (like Zero) and exposed language operators that mapped to the IL opcodes that have been around since .NET Framework 1.0. This means prior to .NET 7, we want to continue treating them differently because there are some minor differences for the caller with regards to return values. There aren’t really any differences for parameters due to the identity conversion and that the callee sees it as the type in its own signature.

For .NET 7 and later (or more specifically, any runtime that defines System.Runtime.CompilerServices.RuntimeFeatures.NumericIntPtr), the compiler no longer emits the NativeInteger attribute and these types are true aliases of eachother (in the same way Int32 and int are true aliases of eachother). So we don’t want or need to treat them differently anymore.