Crossgen2: pass the hidden type arg for wasm array Address thunks

[AndyAyersMS]

Array address methods need a hidden instantiation argument.

Fixes #133307

Note

This PR description was generated with the assistance of GitHub Copilot.

[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: @dotnet/crossgen-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

🔵 Needs a closer look

Although the diff is small, it changes low-level wasm calling/signature behavior in the R2R/JIT interface and should get a final human review for cross-cutting correctness impact.

Pull request overview

This PR fixes a browser-wasm ReadyToRun (Crossgen2) failure caused by a wasm delay-load helper thunk being generated with a signature that omitted the hidden “paramtype” argument required for multidimensional array Address calls, and then re-enables the previously gated smoke test.

Changes:

• Update wasm signature lowering so IsArrayAddressMethod() also triggers emission of the hidden instantiation/type argument in the wasm-level signature.
• Re-enable TestGenericMDArrayBehavior in the crossgen2 smoke test runner by removing the wasm R2R gating.

File summaries

File	Description
src/tests/readytorun/crossgen2/Program.cs	Removes the wasm R2R conditional skip so TestGenericMDArrayBehavior runs again in that configuration.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Includes IsArrayAddressMethod() in lowering-flag computation so generated wasm thunk signatures include the hidden type argument.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

[AndyAyersMS]

@davidwrighton PTAL
fyi @dotnet/wasm-contrib

There may still be an issue with the GCRefMapBuilder, it special cases this method only for X86.

[jkotas]

There may still be an issue with the GCRefMapBuilder, it special cases this method only for X86.

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/GCRefMapBuilder.cs

Lines 97 to 99 in 9c868a6

	// On X86 the Array address method doesn't use IL stubs, and instead has a custom calling convention
	if ((context.Target.Architecture == TargetArchitecture.X86) &&
	methodIsArrayAddressMethod)

This comment and logic look wrong. x86 multidimm array method do use IL stubs like any other architecture. And we should have the hidden arg on all architectures, not just on x86. I think we get away with this since all arguments of the method are integers, there is nothing to report to the GC beyond this and do not notice the mismatch. Could you please update this to be just:
bool hasParamType = (methodRequiresInstArg && !isUnboxingStub) || methodIsArrayAddressMethod;

[AndyAyersMS]

@jkotas thanks - applied exactly as suggested in 29f7ce8, and dropped the (incorrect) x86 comment.

Validation: rebuilt wasm crossgen2, re-ran the crossgen2smoke test (70/70, exit 100) and the ILCompiler.ReadyToRun unit tests (75 passed, 0 failed). No local x64/arm64 R2R artifacts here, so those legs are on CI. To be precise about what that shows: it's absence of a behavioral regression, not direct validation of the ref map contents - as you note, with all-integer args there is nothing to report beyond this, so a mismatch wouldn't surface without GC stress.

One related thing I noticed but did not touch, in case it's worth a separate look: WasmImportThunkPortableEntrypoint.GetData reads MethodFixupSignature.Method but ignores IsInstantiatingStub, while Get_CORINFO_SIG_INFO honors the corresponding suppressHiddenArgument. I couldn't convince myself either way about the case where the exact method is itself canonical. Is that a real divergence, or does something upstream rule it out?

Note

This comment was drafted with AI assistance.

[jkotas]

I couldn't convince myself either way about the case where the exact method is itself canonical. Is that a real divergence, or does something upstream rule it out?

I am not able to tell whether there is an actual problem. If there is one, it should show up as test failure.

[Copilot]

🔵 Needs a closer look

The changes affect WASM lowering and ReadyToRun GC-reference-map layouts, warranting final human validation.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[AndyAyersMS]

Failures are #133702

[AndyAyersMS]

/ba-g known mono test failures