Fix support generic struct arrays with generic TypeSpecs

[josesimoes]

Description

• ResolveToken for a TypeDef instance now resolves generic TypeSpec tokens to their open generic TypeDef, enabling newarr, ldelem.any and stelem.any to succeed on generic struct element types.
• InitializeReference now properly handles a VAR field without generic instance context, falling back to Object instead of faiing, mirroring the existing MVAR behaviour.
• Narrow VAR fallback to array pre-allocation path only.
  • Add allowUnresolvedVarFallback parameter to InitializeReference.
  • Now using this when resolving VAR.
  • Update callers, noticably NewObject as this is the only path reached from ClearElements → NewObjectFromIndex during open-generic array pre-allocation.

Motivation and Context

• newarr Pair<TKey,TValue> inside a generic method emits a generic TypeSpec token. The runtime had no handling for this token class in ResolveToken, causing CLR_E_WRONG_TYPE for newarr, ldelem.any and stelem.any on generic struct arrays.
  Even after resolving the element type, pre-allocating struct slots in the new array calls InitializeReference on each field. For open generic structs the field types are unresolved VAR parameters; without a closed generic context at array-creation time the call unconditionally returned CLR_E_FAIL. Fields are written correctly by subsequent stfld instructions, so initialising them as objects (which are null) is safe.
• Edge case surfaced when adding new test code in MDP Fix minimize failing for generic interface TypeSpecs with no member refs metadata-processor#232.
• Related with Support for generics <T> Home#782.

How Has This Been Tested?

• [tested against Merge generics support in mscorlib CoreLibrary#245].

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies/declarations (update dependencies or assembly declarations and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes update generic type instantiation handling in the CLR. They modify reflection element type selection for array creation, add lenient handling for unresolved generic parameters during field initialization, and simplify type token resolution logic for generic instantiations.

Changes

Cohort / File(s)	Summary
Generic Type Instantiation Handling src/CLR/Core/CLR_RT_HeapBlock_Array.cpp, src/CLR/Core/Execution.cpp, src/CLR/Core/TypeSystem.cpp	Updates reflection element type selection to prefer genericTypeDef for generic instantiations with fallback to cachedElementType; allows InitializeReference to coerce unresolved generic parameters to DATATYPE_OBJECT instead of failing; simplifies ResolveToken logic to directly capture and validate the open generic type definition token for DATATYPE_GENERICINST cases.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title concisely describes the main change (fixing support for generic struct arrays with generic TypeSpecs), is directly related to the core changeset, and follows the requirements.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description clearly relates to the changeset, detailing fixes for generic struct array support and VAR field handling with specific context about motivation and testing.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[josesimoes]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/CLR/Core/Execution.cpp`:
- Around line 2118-2131: The current fallback that sets VAR to DATATYPE_OBJECT
when genericInstance is null is too broad and incorrectly affects callers like
InitializeReference used during static field initialization; narrow the fallback
so only the open-generic pre-allocation path uses DATATYPE_OBJECT. Specifically,
in the block that checks genericInstance and NANOCLR_INDEX_IS_VALID, detect the
pre-allocation scenario (the same condition used when preparing array element
structs for open generics) and only in that case set dt = DATATYPE_OBJECT;
otherwise return/propagate the unresolved/generic error (i.e., preserve failure)
so callers such as InitializeReference (static field init) continue to handle
value-type generic parameters correctly; keep the call to
ResolveGenericTypeParameter and the goto process_datatype for the
normal/closed-generic path.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3619426b-7257-4cdd-9003-be399d7a40b1

📥 Commits

Reviewing files that changed from the base of the PR and between 2df0ad2 and ea07066.

📒 Files selected for processing (3)

• src/CLR/Core/CLR_RT_HeapBlock_Array.cpp
• src/CLR/Core/Execution.cpp
• src/CLR/Core/TypeSystem.cpp