[pcshrosbree]

TL;DR: ILVerify currently stops checking a method when it reaches calli, mkrefany, refanyval or refanytype. This PR adds checks for these instructions so that checking continues, and it still reports every calli as unverifiable. In the .NET 10.0.12 shared framework, 31 methods are no longer aborted, and no other method's results change. I chose defaults for three open questions, which are listed at the end for review.

This follows the reply in #136111:

• calli cannot be verifiable, because the runtime does not track the lifetime of function pointers, and it belongs under [ILVerify] Add option for IL validation without IL verification #37391. So every calli is reported as Unverifiable, and verification continues. Call-site errors such as a wrong number of arguments are still reported. This PR does not add the validation-only mode that [ILVerify] Add option for IL validation without IL verification #37391 asks for.
• Following the reply on varargs, I left arglist unchanged: ImportArgList still throws "RuntimeArgumentHandle not supported in .NET Core".

#136111 still asks for arglist, so this PR contributes to it rather than fixing it. If #136111 is narrowed to the four instructions this PR covers, this PR completes it.

Rules

Section numbers are from ECMA-335, 6th edition.

calli (III.3.20):

• The operand must be a stand-alone signature token (ExpectedSignatureToken).
• The method pointer must be a native int (StackMethod).
• The arguments must be assignable to the call-site signature. For an instance site without explicit, the signature does not give the type of this, so it is only popped. An uninitialized this cannot be passed.
• tail. is checked as for call. The return checks that were in ImportCall are now in CheckTailCallReturn, which call and calli share.
• The return type is pushed.

mkrefany (III.4.19):

• The pointer must be a managed pointer (StackByRef) that is not readonly (ReadOnlyInMkrefany).
• The type it points to must exactly match the type named by the class token (StackUnexpected).
• The class must be accessible (TypeAccess). It may be byref-like (see review point 1).
• TypedReference is pushed.

refanyval (III.4.23): the operand must be a TypedReference. A managed pointer to the class is pushed. Because it may point to a caller's local, returning it is reported (ReturnPtrToStack).

refanytype (III.4.22): the operand must be a TypedReference. RuntimeTypeHandle is pushed.

The two new codes are appended at the end of VerifierError, each with a Strings.resx entry.

Two limits remain:

• ILVerify does not verify a block that is reached only through a block that reported an error, and Unverifiable counts as an error. An error after a calli in the same block is reported, but a later block may not be checked.
• Vararg call sites that pass extra arguments still fail in the shared type system, for both calli and call. This PR does not change that.

Tests

• CalliTests.il has 17 tests and TypedReferenceTests.il has 16, with one rule per test where possible.
• ILVerification.Tests goes from 513 tests on main to 546, all passing.
• I made 27 mutations. In 26 of them, I disabled, inverted or changed one new check or stack effect. The other one adds back the byref-like rejection described in review point 1. Every mutant built and failed at least one test.

Measured impact

I compared builds of main (677ab53) with and without this change, running on linux-x64 under .NET 11 RC 1, with the .NET 10.0.12 shared framework as the reference set.

The figures below were measured before commit 8463836 removed the check comparing a calli signature with the method loaded by ldftn or ldvirtftn. In a separate comparison, builds from before and after that commit gave identical results for every method in the .NET 10.0.13 shared framework and the package sets below.

Shared framework (172 assemblies, 130,146 method bodies). 55 methods contain calli and 3 contain refanytype. None contains mkrefany or refanyval.

	main	This PR
Methods aborted at one of the four instructions	31	0
Methods whose results changed, among the other 130,115		0
New findings in the 31, besides Unverifiable		37

All 37 new findings come after the calli: InitLocals 33, UnmanagedPointer 2 and StackUnexpected 2. The same methods already report these kinds of errors before the calli. Neither of the two new codes fired.

Published packages (388,443 method bodies from hand-written IL packages, packages built with InlineIL.Fody, the 300 most-downloaded packages on nuget.org, and saved dynamic proxies). 149 methods were aborted at one of the four instructions, and ILVerify now continues checking them. They gained six findings, all at or after the instruction. One is a real bug: ImpromptuNinjas.ZStd 1.4.5.5's ZStdDCtx::Copy pushes two arguments for a calli whose signature takes three, and ILVerify now reports a stack underflow. No other method changed, and neither of the two new codes fired.

C# compiler output (SDK 10.0.401). Function-pointer calls now report only Unverifiable at the calli. Methods that use __makeref, __refvalue and __reftype verify with no errors. A method that uses __arglist still fails as before.

Roslyn. Four Roslyn tests quote the old messages: ExtensionTests.AddressOf_TypeReceiver, LocalStateTracingTests.RefArguments_FunctionPointerInvocation, FunctionPointerTests.FunctionPointerInference_ExactInferenceThroughArray_RefKindMatch (in a comment) and CodeGenTests.Issue51228. They would need updating when Roslyn takes a new ILVerify.

Points for review

These questions from #136111 are still open, and I chose a default for each:

1. mkrefany and byref-like classes. This PR follows the augmented spec and accepts them. The 2012 edition of ECMA-335 said a managed pointer cannot point to a typed reference (I.8.6.1.3). The augments replace that with "a managed pointer can point to a byref-like type" (I.8.6.1.2). The old native verifier rejected TypedReference, ArgIterator and RuntimeArgumentHandle (VER_E_RA_PTR_TO_STACK), and the old JIT verifier rejected every byref-like class. I can add a rejection of all byref-like classes if you prefer it.
2. mkrefany type match. The type the pointer points to must exactly match the type named by the class token, so int32& with uint32 is reported. Comparing verification types instead would accept it.
3. Error codes. I added one code per new message. I can reuse existing codes such as TokenResolve or ReadOnlyIllegalWrite instead, or rename these.

Contributes to #136111

Note

This PR was prepared with AI assistance (Anthropic Claude and OpenAI Codex), under my direction. I reviewed it before posting.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[jkotas]

Thanks

[jkotas]

/ba-g opened #136204 on the test failure

[pcshrosbree]

Thank you for the review and merge!