[pcshrosbree]

TL;DR: Since #129118, ILVerify rejects the way C# encodes unmanaged constraints. This PR accepts those constraints. In the 10.0.12 shared framework, all 658 BadTypeSpec errors disappear and verification continues past them. The change is 11 lines in the parser, plus tests.

The change

EcmaSignatureParser.ParseTypeSpec now:

1. Notes whether the blob starts with a custom modifier, then reads the type code with ParseTypeCodeImpl, which skips any custom modifiers and PINNED.
2. Accepts the seven forms it accepted before (PTR, FNPTR, ARRAY, SZARRAY, GENERICINST, VAR, MVAR), with or without modifiers.
3. Accepts CLASS or VALUETYPE (SignatureTypeCode.TypeHandle) only if modifiers came first.

Everything else still calls ReportInvalidTypeSpecEncoding.

As in #129118, a TypeSpec is accepted or rejected in the same way wherever it is used. The TypeSpec OBJECT is still rejected, so extends object (#119536) is still reported. extends class Base modreq(UnmanagedType) is accepted, because the augments allow that TypeSpec, even though the runtime does not load it as a base type.

Why this keeps the intent of #129118

#129118 rejects a TypeSpec if its encoding is not allowed or a shorter encoding is available. A bare CLASS X TypeSpec is redundant, because X can be referenced directly with its TypeDef or TypeRef token. Augments section 5 gives this as the reason: "the indirection through a TypeSpec would serve no purpose". With a custom modifier, that is no longer true. modreq(UnmanagedType) class System.ValueType has no TypeDef or TypeRef form, so the TypeSpec is the only way to write it. Section 3 of the augments adds Type ::= CustomMod* Type to the Type grammar, and section 5 describes the TypeSpec grammar as a subset of Type.

These are still rejected:

• CLASS or VALUETYPE without modifiers (call void class [System.Runtime]System.GC::Collect() makes ilasm emit the TypeSpec CLASS System.GC). No test covered this case before.
• Modifiers followed by a primitive type, such as modopt(IsConst) int32, or by BYREF.
• A TypeSpec used as a modifier type, as before: ParseTypeCodeImpl still calls ReportTypeSpecUsedAsCustomModifier.

ParseTypeCodeImpl skips PINNED wherever it occurs. The seven forms listed above are accepted with leading PINNED. For CLASS or VALUETYPE, the blob must still start with a custom modifier; PINNED may appear between the modifiers and the type code.

crossgen2 and NativeAOT

The parser is shared with ILCompiler.TypeSystem, but only ILVerify implements the partial methods ReportInvalidTypeSpecEncoding and ReportTypeSpecUsedAsCustomModifier (in ILVerification/EcmaSignatureParser.ILVerify.cs). ILCompiler.TypeSystem compiles EcmaSignatureParser.cs without that file, so the calls are removed there. For any blob, ParseTypeSpec reads the same bytes in the same order and returns the same type as on main. The call to ParseTypeCodeImpl moves from after the switch to before it, with the same arguments. ILCompiler.TypeSystem.Tests pass at the current head (356/356, Release).

Tests

• ILTests/TypeSpecModifierTests.il (new): CallUnmanagedConstraintMethod_Valid calls a method constrained where T : unmanaged, with the constraint encoded the way Roslyn does it (1F 0D 12 09). CallThroughClassTypeSpec_Invalid_BadTypeSpec covers CLASS without modifiers.
• ILMetadataReferenceTester.AcceptsTypeSpecsWithCustomModifiersOnAClass (new) runs VerifyMetadataReferences on that assembly. It checks that the unmanaged TypeSpec is not reported, and that the CLASS System.GC TypeSpec is, with BadTypeSpec.

On main, method verification does not report BadTypeSpec for a generic method that only declares the constraint. CallUnmanagedConstraintMethod_Valid therefore calls a method with that constraint. On main, metadata-reference verification reports the constraint's TypeSpec as invalid. The new metadata-reference test checks that this PR removes that report.

ILVerification.Tests: 522/522 in Release and in Debug (main: 519 in Release).

Each guard was checked by mutation (one change per mutant, Release, full suite):

Mutant	Tests that fail
Modified CLASS/VALUETYPE not accepted	CallUnmanagedConstraintMethod_Valid and the new metadata-reference test
CLASS/VALUETYPE accepted without modifiers	CallThroughClassTypeSpec_Invalid_BadTypeSpec and the new metadata-reference test

No other test failed under either mutant.

Framework before and after

ILVerify CLI from this branch and from main (8ab789d9e8a0), over all 172 assemblies of Microsoft.NETCore.App 10.0.12, CLI defaults plus --tokens:

	main	this PR
BadTypeSpec	658 (11 from metadata-reference verification, 647 from method verification)	0
All errors	84,245	84,546

The totals are the CLI's error counts. They include 31 errors without an error code, such as ImportCalli not implemented, which are the same in both runs. At the current head, the results are the same, assembly by assembly, as at this PR's first commit.

Verification of the 647 methods that previously stopped at BadTypeSpec now continues past the TypeSpec. Of those methods, 378 now have no findings. The remaining methods account for all 959 new findings:

Finding	Count
InitLocals	862
UnmanagedPointer	36
ExpectedNumericType	26
StackUnexpected	11
Unverifiable	11
StackByRef	8
ReturnPtrToStack	5

No finding changed in any other method.

Points for review

• Primitives after modifiers. I kept modopt(X) int32 rejected, because a bare int32 TypeSpec is rejected and I know of no compiler that emits the modified form in a TypeSpec. Accepting any Type after the modifiers would also follow from the augments; I chose the narrower rule.
• OBJECT and STRING after modifiers are rejected for the same reason. This PR accepts a modified object when it uses CLASS System.Object.
• Interface kind. Neither main nor this PR checks the rule in II.22.23 that a type listed as an implemented interface is an interface. I can fix that in a separate PR.
• No change to Ecma-335-Augments.md. Sections 3 and 5 together already allow the modified form.

Fixes #136142

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.

[Copilot]

🟢 Approval recommended

The narrow parser change preserves validation guards and includes targeted regression coverage, with no unresolved findings.

No open issues 🎉

What changed in this PR

Fixes ILVerify’s rejection of C# unmanaged constraints by accepting leading custom modifiers in TypeSpecs while preserving existing validation guards.

Changes:

• Accepts modified class/value-type TypeSpecs.
• Adds positive and negative method-verification tests.
• Checks metadata-reference diagnostics for invalid encodings.

Builds and tests were not independently run.

File	Description
src/​coreclr/​tools/​ILVerification.Tests/​ILTests/​TypeSpecModifierTests.ilproj	Registers the new IL test assembly.
src/​coreclr/​tools/​ILVerification.Tests/​ILTests/​TypeSpecModifierTests.il	Covers accepted constraints and rejected TypeSpecs.
src/​coreclr/​tools/​ILVerification.Tests/​ILMetadataReferenceTester.cs	Checks TypeSpec metadata diagnostics.
src/​coreclr/​tools/​Common/​TypeSystem/​Ecma/​EcmaSignatureParser.cs	Handles leading modifiers before validating TypeSpecs.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The focused parser change has targeted acceptance and rejection coverage, with no unresolved findings.

No open issues 🎉

_{Review effort: Balanced}

[pcshrosbree]

@jkotas, the test move you asked for is in e8ff536, the only commit since your approval. That push turned off auto-merge, and the PR needs your approval again.