[wasm][R2R] Create manifest token when type reference wasn't pre-registered

[pavelsavara]

Summary

Fixes a crossgen2 ReadyToRun compilation failure that is specific to the WebAssembly target.

Problem

When crossgen2 targets WebAssembly, a method that would normally register a type token during IL token resolution can be skipped by the JIT (JitWasmNyiToR2RUnsupported), while a TypeFixupSignature for that type is still emitted. At manifest emission time, ModuleTokenResolver.GetModuleTokenForType does a reverse lookup via _manifestMutableModule.TryGetExistingEntityHandle(type), which returns null because nothing pre-registered the reference. The resolver then falls through to throw new NotImplementedException(...), which aborts the R2R compile.

This was observed while R2R-compiling System.Runtime.InteropServices.JavaScript.dll for browser-wasm, where the reverse lookup fails for [S.P.CoreLib]System.Reflection.MemberInfo.

Fix

In the allowDynamicallyCreatedReference branch, when the existing-handle lookup returns null, create the manifest reference on demand via _manifestMutableModule.TryGetEntityHandle(type), guarded by !DisableNewTokens so it only runs while new tokens are still allowed (this path executes before ManifestMetadataTableNode sets DisableNewTokens). This mirrors how other manifest references are produced.

Notes

• Scoped to a single method. The added code only runs when the pre-existing reverse lookup fails, so there is no behavior change for the PE/x64 path where the type is already registered.

Note

This change and description were prepared 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.

[Copilot]

Pull request overview

Fixes a crossgen2 ReadyToRun compilation failure path by allowing ModuleTokenResolver.GetModuleTokenForType to create a manifest metadata reference on-demand when the existing reverse lookup can’t find a pre-registered handle.

Changes:

• Add a fallback in GetModuleTokenForType to call MutableModule.TryGetEntityHandle(type) when TryGetExistingEntityHandle(type) returns null.
• Guard the fallback on DisableNewTokens to avoid creating new metadata tokens during the “no new tokens” phase.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[adamperlin]

This looks reasonable to me aside from the copilot feedback above about a possible synchronization issue. Can we open an issue to revisit this if possible? Hopefully JitNyiWasmToR2RUnsupported will be able to go away soon, in which case we should remember to remove this workaround.

[pavelsavara]

possible synchronization issue

Is there better way how to do this ? This is a lookup with side-effects.
Could we for example insert such token as the time when we emit JitNyiWasmToR2RUnsupported ?

[AndyAyersMS]

I think we will still need/want the ability for the JIT to fail to produce R2R even after we've removed the blanket NYI_WASM fail-over.

So crossgen needs to tolerate this failure cleanly. It feels to me like it is committing to emit some things too early, before we know for sure if the method is going to be R2R'd. And so we end up trying to emit something partial. This fix may be a reasonable workaround for now, but I think there may be a better approach out there.

[jkoritzinsky]

I think this fixing a similar issue as #131610. Can we do a similar fix here as we have in that pr?