Validate invalid base type declarations in ILVerify

[pkuyo]

Fixes #119536

This adds ILVerify validation for invalid class base type declarations.

The original issue reports a case where ILAsm accepts a type declared with
extends object, but the resulting type cannot be loaded by the runtime.
ILVerify previously accepted that assembly without reporting an error.

This change reports InvalidBaseType for invalid base type declarations rather
than special-casing only the exact extends object spelling.

Tests added in BaseTypeTests.il:

• ObjectTypeSpecBase_InvalidType_InvalidBaseType

  • Covers the original repro: a class declared with extends object.
  • Expected result: InvalidBaseType.

• NilBaseInterface_ValidType_Valid

  • Ensures interfaces with no class base continue to verify successfully.

• GenericClassTypeSpecBase_ValidType_Valid

  • Ensures valid generic class TypeSpec bases are still accepted.

• ValueTypeBase_InvalidType_InvalidBaseType

  • Ensures a non-generic value type cannot be used as a class base.

• GenericValueTypeSpecBase_InvalidType_InvalidBaseType

  • Ensures a generic value type instantiation cannot be used as a class base.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib
See info in area-owners.md if you want to be subscribed.

[pkuyo]

@dotnet-policy-service agree

[jkotas]

Is this any better than just calling _module.GetType(typeHandle)?

[pkuyo]

I tried that locally again, using only _module.GetType(typeHandle) does not catch the #119536 repro. (ObjectTypeSpecBase_InvalidType_InvalidBaseType)

In the extends object case, _module.GetType(typeHandle) resolves the TypeSpec to System.Object, which loses the issue that the base type was encoded as an invalid TypeSpec in the extends clause.

[jkotas]

If you would like to check for invalid type specs, it should be done in the central location where typespecs are decoded so that it applies to all of them. The problem is not specific to base type.

[pkuyo]

Thanks, I tried moving this into EcmaModule.GetType, but I don't think this check can be global.

EcmaModule.GetType is context-independent. A top-level built-in TypeSpec like ELEMENT_TYPE_OBJECT is invalid in a TypeDef extends clause, but it is not invalid in every context. For example, CoreCLR accepts stobj with a TypeSpec object token, and ILVerification already has a similar existing test case using stobj string ( [LoadStoreIndirectTests] StoreObject.ValidTypeToken).

Rejecting these TypeSpecs in EcmaModule.GetType would therefore make ILVerify reject IL that is accepted outside of base type declarations. I think this validation should stay in the base type verification path, where we know the token is being used as a class base type.

[jkotas]

TypeSpec with object token is invalid in every context according to the spec. Look for TypeSpecBlob grammar in ECMA-335.

ILVerify is meant to check for speced behavior. It is not meant to check for what CoreCLR happens to accept. The runtime often accepts more than what's allowed by the spec.