Skip to content

Read IntPtr as nint where they are the same type - #107

Merged
Mpdreamz merged 2 commits into
mainfrom
numeric-intptr
Nov 15, 2026
Merged

Mpdreamz merged 2 commits into
mainfrom
numeric-intptr

Conversation

@Mpdreamz

@Mpdreamz Mpdreamz commented Nov 15, 2026 •

Copy link
Copy Markdown
Contributor

Closes one of the known gaps.

Since C# 11, on a runtime with RuntimeFeature.NumericIntPtr (.NET 7 and later), IntPtr and nint are the same type. The compiler no longer emits NativeIntegerAttribute, so the reader showed every nint in a modern library as IntPtr. The rule now:

  • Reads as nint and nuint: an assembly whose TargetFrameworkAttribute says .NET 7 or later, or a core library that declares NumericIntPtr itself.
  • Keeps IntPtr: anything older, unless NativeIntegerAttribute says otherwise, as before.
-    IntPtr Native(UIntPtr value)
+    nint Native(nuint value)

The signatures sample now declares itself a .NET 11 build, as every SDK build does. Roslyn-compiled tests otherwise carry no target framework. The comparison now treats nint and IntPtr as the same type even when comparing exactly. Before this, a committed file with IntPtr compared with a new one with nint would have been reported as a Minor "nullability" change. A test covers it, and dropping that rule makes the test fail.

Checks: mise run ci passes, with 82 library tests and 630 tool tests, and api/ is unchanged.

🤖 Generated with Claude Code

Since C# 11, on a runtime that has RuntimeFeature.NumericIntPtr (.NET 7 and later), IntPtr and nint are one type and
the compiler no longer marks which a signature meant, so the reader showed every nint in a modern library as IntPtr.
An assembly that targets .NET 7 or later, or a core library that declares NumericIntPtr itself, now reads them as
nint and nuint; one for an older runtime keeps IntPtr where NativeIntegerAttribute does not say otherwise.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Mpdreamz Mpdreamz added the bug A defect fixed (patch) label Nov 15, 2026
An .api file written before this reader has IntPtr where a new one has nint; they are one type to C# since 11, so
comparing them is not a change, rather than a Minor one noted as nullability.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Mpdreamz
Mpdreamz merged commit 8f2c120 into main Nov 15, 2026
7 checks passed
@Mpdreamz
Mpdreamz deleted the numeric-intptr branch November 15, 2026 06:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug A defect fixed (patch)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant