[wasm] Compute CoreCLR P/Invoke struct sizes with crossgen2's type system

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?

[radekdoulik]

Replaces the hardcoded struct-size table in the CoreCLR wasm P/Invoke generator with crossgen2's real field-layout engine.

The problem

ManagedToNativeGenerator computed wasm ABI signature strings from System.Reflection.MetadataLoadContext, which has no field-layout engine. Struct sizes therefore came from a 7-entry hardcoded table, and anything outside it was a hard build error:

error WASM0067: SignatureMapper: unknown multi-field struct 'X' (fields: N)
- add its size to s_knownStructSizes in SignatureMapper.cs

Size matters here because the CoreCLR interpreter lays struct arguments out inline across 8-byte slots — TokenToSlotCount returns max((size + 7) / 8, 1) for an S<N> token. A wrong N misaligns the interpreter frame.

(Mono's generator needs none of this: its alphabet has no S, and it encodes every struct as a pointer, so it never had to know a size.)

The change

crossgen2 gains --generate-portable-callhelpers <dir>, which writes the three C++ call-helper files directly. It sets up its type system exactly as for a real wasm compilation, scans the input assemblies, and emits — no JIT, no R2R image. The option requires --targetarch wasm with --targetos browser|wasi.

The CoreCLR half of the MSBuild task is then deleted outright, not adapted: ManagedToNativeGenerator, PInvokeCollector, PInvokeTableGenerator, SignatureMapper, InternalCallSignatureCollector, InterpToNativeGenerator all go. _CoreCLRGenerateManagedToNative keeps its name and position in the target graph; only its final step changes from <UsingTask> to <Exec>. The scripts that regenerate the checked-in tables move next to their output under src/coreclr/vm/wasm/ and now drive generate-coreclr-helpers.proj, which imports the shared eng/wasm/WasmPInvokeModules.props module list added by #131866 and hands crossgen2 a response file. Mono's generator is untouched.

That is the shape of the diff: −2246 lines under src/tasks, +1575 under src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers. Net ~+36 lines across 40 files. It is a move, not an addition — the second implementation of wasm ABI lowering is gone, and the one that remains is the one the JIT interface itself calls.

Because the whole pipeline now runs inside the compiler, it reuses Internal.TypeSystem for metadata and WasmLowering for the ABI. Sizes are computed, not enumerated. The only change to WasmLowering is widening WasmValueTypeToSigChar from private to internal.

Naming

Portable entry points exist for any platform that cannot generate code at run time; wasm is the only one today, but game consoles are the same shape. Per review feedback nothing in this functionality is named after wasm. The generator lives in ILCompiler.PortableCallHelpers with PortableCallHelpersGenerator as its entry point, the MSBuild override is $(PortableCallHelpersGeneratorPath), and the symbols the runtime and the generated tables agree on were renamed on both sides at once:

before	after
StringToWasmSigThunk	StringToPortableSigThunk
g_wasmThunks	g_portableCallHelperThunks
g_wasmThunksCount	g_portableCallHelperThunksCount
wasm_ret_S<n>	portable_callhelper_ret_S<n>
g_wasmPortableEntryPointThunks	g_portableEntryPointThunks

What keeps wasm in its name is what is genuinely about wasm: the ABI in WasmLowering, the --targetos browser|wasi requirement, and the wasm-specific corerun the runtime tests link.

Finding crossgen2 at build time

Three acquisition paths, tried in order:

• Override — $(PortableCallHelpersGeneratorPath), which has to name a crossgen2 executable. Every path above resolves a self-contained one, so there is no IL-only fallback; pointing the override at crossgen2.dll is rejected with that message rather than failing inside Exec.
• In repo — $(Crossgen2InBuildDir). crossgen2 is built unconditionally by the clr subset.
• Out of repo — the wasm-tools workload now declares the existing Microsoft.NETCore.App.Crossgen2.<host-rid> pack, whose Sdk/Sdk.props defines $(Crossgen2ToolPath).

The SDK already resolves this pack, but only when PublishReadyToRun is set, which wasm CoreCLR apps never set — hence declaring it in the workload instead. It costs ~12.5 MB there. If none of the three resolve, the targets error explicitly rather than passing an empty path down.

Note the pack is named for the machine that runs crossgen2, not the target: generation never loads the JIT, so a host-targeting crossgen2 answers wasm ABI questions correctly.

Regenerating the checked-in tables resolves crossgen2 separately: generate-coreclr-helpers.proj takes the self-contained one from the same clr+libs -os <flavor> build that produced the assemblies it scans, so a single command per flavor supplies both the tool and the scan path.

One CI wrinkle: no wasm leg produced a crossgen2 pack, so the workload-testing legs had nothing to install from their local feed. Microsoft.NETCore.App.Crossgen2.Host.sfxproj pins the RID to the build host and is now built by the CoreCLR browser-wasm leg behind an opt-in property, then staged alongside the CoreCLR runtime pack. The official build is untouched — it already publishes this pack from the host platform legs.

Unresolved P/Invoke modules no longer warn

The deleted task warned WASM0066 for every DllImport whose module did not resolve to a linked-in native library. That was a CoreCLR-only divergence — Mono's generator silently skips the same imports — and it fires on ordinary cross-platform code that never executes on wasm. #131874 reports ten of them from SkiaSharp alone on a shipped Preview 7 SDK (ole32.dll ×2, Kernel32.dll ×6, libEGL.dll, libc). In-tree it had already accumulated two NoWarn suppressions and a WarnOnUnresolvedPInvokeModules=false on the wasi leg; all three are removed here along with the warning and the --no-warn-unresolved-directpinvoke opt-out that existed only to silence it.

It is deleted rather than re-plumbed because an unresolved module is not knowably wrong at build time. callhelpers_pinvoke_override returns nullptr on a miss, so resolution falls through to the normal path and a call that actually happens throws DllNotFoundException naming the module — the same diagnostic every other .NET platform gives. Dropping a warning is strictly loosening, so this is not a breaking change.

Exported callbacks with an ambiguous name are rejected

An export wrapper resolves its MethodDesc through LookupUnmanagedCallersOnlyMethodByName, which walks the declaring type and takes the first [UnmanagedCallersOnly] method whose name matches, comparing no signature. Two exported overloads therefore resolve to the same method, whichever the walk reaches first, and one of the wrappers calls it with the wrong arguments. Everything the generator controls does carry the arity — the thunk keys are Handle#1:… against Handle#2:…, and the symbols differ by parameter type — so the existing duplicate-key and duplicate-symbol checks both pass. Generation now fails instead, naming both signatures.

Only exports are rejected. A callback the runtime resolves through g_ReverseThunks is found by the arity-aware key and has its MethodDesc filled in before the wrapper ever runs, so it never reaches the name lookup; same-named callbacks that are not exported keep working. This makes the case a build error rather than fixing it, and should be removed if the runtime ever resolves these unambiguously.

Verification

• Regeneration reproduces the committed helpers. Apart from the symbol rename above, the generated tables are byte for byte what was checked in, and zero WASM0001/WASM0060/WASM0061/WASM0062 warnings fire across a full CoreLib+libraries scan, so no fallback guard is hit. One caveat worth stating: the checked-in P/Invoke table is already slightly stale against main independently of this PR - regenerating after a fresh clr+libs drops CompressionNative_CompressBound, which nothing P/Invokes any more, and shifts one attribution comment. That drift is left alone here rather than folded into a rename.
• ILCompiler.ReadyToRun.Tests, built for browser-wasm: 73 passed, 0 failed, 37 skipped (the skips are the classes gated on a non-wasm target). WasmArgumentLayoutTests goes from 17 to 24 test methods. The five cases covering the rejection above were checked against a disabled check: exactly the two that expect rejection fail, so they test it rather than agree with it.
• WasmAppBuilder still builds for bothnet11.0 and net472.
• clr+libs builds clean for both browser and wasi.
• Both flavors build end to end from the in-tree samples: Wasm.Browser.Sample with a native relink, and Wasi.Console.Sample published for wasi. Injecting per-architecture native payloads, a non-PE file and duplicate-culture satellites into the bundle leaves both green, with none of them reaching the generator's response file.
• Regenerating the checked-in tables through the new project reproduces them byte for byte.
• The renamed runtime contract was checked by building it, not by reading: the rebuilt libcoreclr_static.a exports g_portableCallHelperThunks and no g_wasmThunks, and the browser sample compiles and links its own generated tables against it.

Seven defects were found and fixed while reviewing this, all with zero baseline drift:

1. String constructors produced dead thunks.MetadataType.GetMethods() returns constructors where Type.GetMethods(BindingFlags) structurally never did, so the port added 5 interp-to-managed thunks for System.String's 9 InternalCall ctors. The VM never asks for those keys — GetCookieForCalliSig and GetPortableEntryPointToInterpreterThunk both special-case IsCtor() && IsString()before any signature lookup, because crossgen2 compiles String ctors as static factories. Now skipped, restoring a zero-diff baseline.
2. By-reference struct parameters were declared as scalars.GenPInvokeDecl consulted the real ABI for returns but the parameter path unwrapped any single-field struct without checking the field fills it. For [StructLayout(Size = 16)] struct PaddedLong { long Value; } one generated file contained void RetPaddedLong (void *) alongside void UsePaddedLong (int64_t) — the same type in two positions, disagreeing. The caller passes an i32 pointer, so that is a wasm value-type mismatch, not a spelling difference. Both positions now go through one IsPassedByReference helper. No P/Invoke in CoreLib or the libraries takes this shape today, which is why it went unnoticed; it matters for the arbitrary user structs this change exists to support.
3. Culture-sensitive sort in generated output. The assembly-attribution comment builder was the only sort in the file without an explicit comparer, making output locale-dependent. Now StringComparer.Ordinal, like its neighbours.
4. A valueless --ignored-directpinvoke reached the response file. Item batching over an empty collection still evaluates the element once with an empty %(Identity), so Include="--ignored-directpinvoke;%(...)" wrote a bare option. crossgen2 reads one token per line and binds the next one as the value, silently swallowing the first managed assembly — normally System.Private.CoreLib, which the targets add explicitly and which sorts first. _WasmIgnoredPInvokeModules was only populated under InvariantGlobalization, so the broken shape was the default configuration. Both module options were guarded on a non-empty identity; --ignored-directpinvoke has since been dropped outright, made dead by the WASM0066 removal, so only the --directpinvoke guard remains — in the browser, wasi and corerun test targets. The in-repo regeneration script builds its own argument list, which is why the byte-identical baseline could not catch this.
5. Multi-segment types were mistaken for by-reference structs.InteropSignature.GetAbiToken treated every type that LowerToAbiType leaves alone as a by-reference struct, but the compiler's own GetSignature splits that case: a type lowering to several segments gets a <slotChar><slotCount> token instead. Int128 therefore encoded as A16, and IsPassedByReference — which tests the first character for S/A — declared it void * while the ABI passes it by value in two slots. Same class of mismatch as (2). It also hid these types from the multi-slot rejection that exists to turn them into a clean diagnostic. GetAbiToken now consults TryGetMultiSegmentLayout first. The regression test asserts that the two encoders agree rather than pinning literal tokens, since that is the invariant both this and (2) broke.
6. Duplicate simple names aborted the build. crossgen2's input-file-path parser rejects two inputs sharing a simple name. The deleted task filtered unmanaged binaries out first; the port handed the app bundle straight to the strict parser, so any app carrying per-architecture native payloads died during argument parsing — KernelTraceControl.dll from Microsoft.Diagnostics.Tracing.TraceEvent is what CI hit. An earlier revision of this PR relaxed the parser for the generator, but that leaned on crossgen2's corert#2785 leniency — the same workaround Remove corert#2785 BadImageFormatException workaround from ILCompiler #127591 had just removed from ILCompiler — and it only ever covered native PE files, since a .dll that is not a PE at all escapes the TypeSystemException.BadImageFormatException catch as a raw System.BadImageFormatException and takes the build down. The list is narrowed in MSBuild instead, by a FilterManagedAssemblies task built on the same Utils.IsManagedAssembly helper that mono's generator (FilterOutUnmanagedBinaries) and ILLink (ComputeManagedAssemblies) already use on this path. crossgen2's shared argument handling is back to a zero-line diff against main, and the browser and wasi targets both hand it a managed-only list. The task also collapses duplicate simple names, which culture satellites produce; unmanaged files are dropped first, so a native payload can never claim a name ahead of the managed assembly sharing it.
7. An unresolved P/Invoke poisoned its module. The set that keeps each unresolved module to a single log line was also short-circuiting the scan loop, so once a module had been recorded every later P/Invoke naming it was skipped — including one that did resolve. A module reached only through [WasmImportLinkage] therefore vanished from the table whenever an unresolved import of the same module happened to be scanned first, leaving a missing wasm import to fail at run time rather than at build time. Only the logging is suppressed now. Found in review and confirmed with a probe declaring both an unresolved and a [WasmImportLinkage] import of one module: absent before the fix, present after, with a linkage-only control unaffected either way.

Not verified

• CI has not yet completed a fully green run, which is why this stays draft. The first run against this design surfaced defect (6) on browser-wasm linux Release LibraryTestsCoreCLR, the only failing leg at the time; runs since then have been against a moving base. The CoreCLR_WasmBuildTests legs are the ones that matter most now that [browser] Run Wasm.Build.Tests on CoreCLR the same way as Mono #132478 broadened what CoreCLR actually runs there.
• The relink path was exercised with a synthetic MSBuild project, not a real Wasm.Build.Tests run. Fix (4) was reproduced and confirmed fixed that way, in both the default and InvariantGlobalization configurations, but has no automated coverage.
• Fix (2) has no unit test. The wasm test harness synthesizes types from CoreLib ValueTuple, which cannot express [StructLayout(Size = …)] padding, so covering it needs a harness extension. It was verified end to end against the real generator instead.
• The wasi runtime was not rebuilt to link-test the renamed symbols. It shares the header and the generator with browser, which was linked end to end, so this is left to CI.
• generate-coreclr-helpers.cmd has never been executed — there is no Windows host available here. Two bugs in it were caught by review and by reading (scan-path overrides forwarded unquoted, and %~dp0 read after the argument loop, which SHIFT invalidates); the .sh equivalent of each is covered.
• All local runs were on macOS/arm64. Windows and Linux hosts are covered only by this PR's CI — hence draft.

Cost

The wasm-tools workload gains the Microsoft.NETCore.App.Crossgen2.<host-rid> pack, ~12.5 MB on disk for anyone who installs it. Most of that is the single-file apphost.

An earlier revision also shipped crossgen2 to Helix as a ~36 MB Wasm.Build.Tests correlation payload, because that leg built test apps straight out of the repo. #132478 moved CoreCLR WBT onto the real workload, so the generated apps now resolve crossgen2 from the pack like any other consumer and the payload — along with the artifact copy that fed it — is gone.

What this does not do

• Does not give wasi an out-of-repo acquisition path. wasi-experimental extends microsoft-net-runtime-mono-tooling, not wasm-tools, so it picks up no crossgen2 pack; the targets error explicitly there. Browser is the shipping wasm/CoreCLR target and is covered.
• Does not re-enable any of the tests disabled in [browser-wasm] CoreCLR runtime tests blocked on interop gaps after test-specific corerun enablement #131811; that is follow-up work.
• Does not address the generic-callback half of gap Get core-setup building in the consolidated repo. #2, which is rejected by a separate blittability check in PInvokeCollector, nor gaps Define a root README.md #3–[master] Update dependencies from dotnet/coreclr #7.
• 'V' (v128) still has no case in the C++ emission helpers. Pre-existing, and still fails loudly rather than silently.
• Reverse thunks allocate one int64_t slot per managed parameter, while a by-value struct argument occupies ceil(size/8) interpreter slots. No [UnmanagedCallersOnly] callback in CoreLib or the libraries takes a by-value struct — there are zero struct-typed reverse thunks in either generated baseline — so nothing exercises this. The old generator rejected such callbacks with WASM0067; this one accepts them, so the failure mode for user code would be a bad thunk rather than a diagnostic. Wants a follow-up.
• Reverse thunks also pack their arguments with (int64_t)argN, which converts numerically instead of copying bits, so a float or double callback parameter would be truncated rather than reinterpreted. Carried over verbatim from the old generator, and equally latent: every reverse thunk in both baselines takes only pointer and integer parameters. Wants the same follow-up.
• Does not give the wasi generator the webcil remap the browser target carries. Published R2R images are webcil, which the managed-assembly filter cannot parse; wasi has no R2R publish today so the remap would have nothing to do, but it will need one if that changes.
• Multi-slot types (Int128, Vector256, …) are rejected at the thunk emitter rather than at the interop boundary, so the diagnostic reads differently than the old WASM0068. Still a clean crossgen2 : error : with exit 1. No such P/Invoke exists today.

Relationship to #131811

Contributes to #131811, closing blocking gap #1 and the struct half of gap #2. Verified for gap #2: a 3-int struct and a 5-double struct in [UnmanagedFunctionPointer] delegate signatures now resolve to vS12 / S12i / vS40i; neither struct was in the old table, so all three previously threw NotSupportedException: Unsupported parameter type.

Review notes

Review the final tree rather than the commits in order — the design went through two discarded revisions. The first packaged this as a standalone ILCompiler.Wasm.Lowering tool; @jkotas asked why it wasn't simply a crossgen2 option, which was right, since every extraction existed only to give a second host something to link against. The second exposed --wasm-abi-query, a stdin/stdout protocol the task called into. This revision drops the protocol and the task with it: if crossgen2 already has the type system and the lowering, it may as well write the files.

That also removes the residual risk called out in the previous revision — WasmLoweringFlags is no longer duplicated on the task side, because there is no task side.

Note

This pull request description was drafted with the help 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.

[radekdoulik]

This should resolve #131874

[Copilot]

Pull request overview

This PR updates the CoreCLR WebAssembly P/Invoke helper generation pipeline to compute wasm ABI struct sizing and signature lowering via crossgen2’s type system (hosted in a new out-of-process tool), replacing the previous hardcoded/reflective size logic that couldn’t reliably handle field layout or constructed generics.

Changes:

• Add ILCompiler.Wasm.Lowering as an out-of-proc “signature resolver” tool and wire ManagedToNativeGenerator to query it for ABI tokens and full method signatures.
• Refactor wasm lowering/shared helpers in the compiler toolchain (type-cache interface, moved wasm type encoding, split MethodDesc-facing lowering).
• Add parity tests to ensure the standalone resolver produces the same signatures as crossgen2.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/WasmAppBuilder.csproj	Builds the resolver tool in RunGenerator and passes its path into ManagedToNativeGenerator.
src/tasks/WasmAppBuilder/IcallTableGenerator.cs	Requires an injected CoreCLR SignatureMapper when generating CoreCLR icall signatures.
src/tasks/WasmAppBuilder/coreclr/WasmLoweringFlags.cs	Task-local copy of lowering flags (mirrors compiler enum values).
src/tasks/WasmAppBuilder/coreclr/WasmAbiTypeResolver.cs	New resolver client that runs ILCompiler.Wasm.Lowering once and queries over stdin/stdout.
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Converts from static helper + hardcoded struct sizes to instance-based mapper backed by resolver.
src/tasks/WasmAppBuilder/coreclr/PInvokeTableGenerator.cs	Routes signature/name token decisions through the new SignatureMapper instance.
src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs	Uses resolver-backed signature computation; skips open generic callback delegates.
src/tasks/WasmAppBuilder/coreclr/ManagedToNativeGenerator.cs	Adds SignatureResolverPath/DotNetHostPath and initializes resolver + mapper for generation.
src/tasks/WasmAppBuilder/coreclr/IWasmAbiTypeResolver.cs	New abstraction for “type token” and “method signature” ABI queries.
src/tasks/WasmAppBuilder/coreclr/InternalCallSignatureCollector.cs	Uses resolver-based lowering for InternalCall signatures; skips generic InternalCalls.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Ships the resolver tool in the SDK pack output layout.
src/coreclr/tools/Common/JitInterface/WasmLowering.MethodDesc.cs	New split file for MethodDesc-based lowering + flag computation.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Refactors to use IWasmTypeCacheContext and narrows API surface in this file.
src/coreclr/tools/Common/Compiler/IWasmTypeCacheContext.cs	New interface for caching/round-tripping wasm-lowered struct/v128 types.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.Encoding.cs	Splits encoding/mangling/JIT interface conversions out of WasmTypes.cs.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_Wasm/WasmTypes.cs	Keeps the wasm type model “type-system only” and makes types partial to split helpers.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Implements IWasmTypeCacheContext on the compiler context.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmTypeSystemContext.cs	New minimal wasm-configured type system context used by the resolver tool.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmMetadataFieldLayoutAlgorithm.cs	New wasm field-layout algorithm mirroring crossgen2 instance layout logic.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/WasmAbiTypeResolver.cs	Resolver API implementation: per-type token and per-method signature queries.
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/Program.cs	Implements the stdin/stdout query server protocol (“ready”, t ..., m ...).
src/coreclr/tools/aot/ILCompiler.Wasm.Lowering/ILCompiler.Wasm.Lowering.csproj	New tool project, links shared lowering/type sources and pins output path.
src/coreclr/tools/aot/ILCompiler.TypeSystem/ILCompiler.TypeSystem.csproj	Grants internals visibility to the resolver tool.
src/coreclr/tools/aot/ILCompiler.RyuJit/ILCompiler.RyuJit.csproj	Includes the new WasmLowering.MethodDesc.cs split file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Includes split wasm encoding + cache interface + MethodDesc lowering file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/VectorOfTFieldLayoutAlgorithm.cs	Extracted Vector<T> layout algorithm into a standalone file.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs	Removes the now-extracted nested VectorOfTFieldLayoutAlgorithm type.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmLoweringParityTests.cs	New parity tests comparing crossgen2 vs resolver lowering across CoreLib.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ILCompiler.ReadyToRun.Tests.csproj	Adds aliased reference to the resolver tool for side-by-side parity testing.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Includes split wasm encoding + cache interface file.
Directory.Build.props	Adds WasmSignatureResolverDir for pinned resolver output placement.

[jkotas]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

[radekdoulik]

Would it be better to expose this as crossgen command line option instead of repackaging large part of crossgen in a new tool?

That could work too. We don't include crossgen in the packages yet IIRC, I can add it in this PR though. I will try it.

For the record, the new tool is 632K, crossgen pack is 36M (measured on mac). We will ship the crossgen anyway, so it indeed makes sense to add the new option instead of the new tool.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmAbiQuery.cs:49

• This type doesn’t appear to need to be public. ILCompiler.ReadyToRun already declares InternalsVisibleTo for ILCompiler.ReadyToRun.Tests, so making this internal would reduce accidental surface area without impacting the crossgen2 entrypoint or tests.

 public static class WasmAbiQuery
{

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (or passed incorrectly via programmatic use), platform-attribute filtering becomes nonsensical and the behavior will be confusing. Fail fast with a clear diagnostic when TargetOS is not provided.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeTableGenerator.cs:97

• This generator code is in the AOT/tooling space and the repo’s core-runtime guidance calls out avoiding LINQ in low-level compiler codebases. This file uses multiple LINQ pipelines (Where/OrderBy/GroupBy/Select) in hot-ish generation loops, which adds allocations and makes debugging harder. Prefer explicit loops and pre-sized collections here to match the rest of the ILCompiler codebase style and reduce overhead.

 var pinvokesGroupedByEntryPoint = pinvokes
.Where(l => modules.Contains(l.Module))
.OrderBy(l => l.EntryPoint, StringComparer.Ordinal)
.GroupBy(CEntryPoint, StringComparer.Ordinal);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:34

• FilterManagedAssemblies.Execute dereferences the nullable Assemblies property (Assemblies.Length and foreach). If MSBuild ever invokes the task without setting Assemblies, this will throw a NullReferenceException instead of producing a normal MSBuild error, making the failure harder to diagnose.

• Files reviewed: 52/52 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:57

• PortableCallHelpersGenerator.Run validates OutputDirectory but not TargetOS. If TargetOS is missing/empty (e.g., API usage outside the command-line path), the generator will fail later with less actionable errors when evaluating platform attributes. Consider validating TargetOS up-front (and restricting it to the supported values) to keep failures deterministic and user-facing diagnostics clear.

 // An empty directory would quietly write the files next to whatever the current
// directory happens to be, so name it as the error it is.
if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:706

• The targets validate that $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but they don't validate that the resolved executable actually exists. When $(Crossgen2ToolPath) is set incorrectly, the build will fail inside <Exec> with a less actionable error. Add an Exists(...) check here (similar to the test corerun targets) to fail early with a clear message.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:170
• Like the browser targets, this validates $(PortableCallHelpersGeneratorPath) is non-empty and not a .dll, but it doesn't validate that the resolved tool exists. If $(Crossgen2ToolPath) is set but points to a non-existent path, the build fails at <Exec> with a less actionable error. Add an Exists(...) check for a clearer failure mode.

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:36

• FilterManagedAssemblies keeps the first file encountered for each simple name, but Assemblies ordering can be nondeterministic (e.g., wildcards / filesystem enumeration). That makes the retained managed assembly (and therefore generated callhelpers output) potentially nondeterministic when duplicates exist (satellite assemblies, duplicate simple names). Sorting by FullPath before filtering would make this deterministic.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102
• EntryPoint is a get-only string but it’s only assigned when [UnmanagedCallersOnly] has an EntryPoint named argument. For non-exported callbacks this leaves the property at its default (null), which is easy to misuse later and may break if nullable analysis is enabled for this project.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

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

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:56

• Run() validates OutputDirectory but does not validate TargetOS. If TargetOS is missing/empty, generation will fail later in less actionable ways (e.g., platform-attribute matching assuming a non-empty target OS). Add an explicit validation before calling Generate.

 if (string.IsNullOrEmpty(options.OutputDirectory))
throw new LogAsErrorException("--generate-portable-callhelpers needs a directory to write to.");
Generate(context, options, log);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• The FilterManagedAssemblies task drops duplicate simple names by keeping the first item encountered, but the input item order is not guaranteed to be stable. This can make the chosen “winning” assembly nondeterministic across builds, which risks nondeterministic generated callhelper output.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36
• PInvokeInfo implements IEquatable, but the Equals signature doesn’t accept null. If nullable annotations are enabled, this typically produces nullability mismatch warnings; even without NRT it’s better to reflect the contract explicitly and avoid the extra as-cast nullability ambiguity.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:102

• PInvokeCallback.EntryPoint is only set for exported callbacks, and EntrySymbol is assigned later during emission. Declaring these as non-nullable makes it easy to accidentally consume them before initialization (and can trigger nullable warnings in projects with NRT enabled).

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions exposes required values (OutputDirectory/TargetOS) as non-nullable properties without defaults or a requirement. This makes it easy to construct invalid options that will fail later (or produce nullability warnings if enabled). Consider marking these as required so invalid states are unrepresentable.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/mono/wasi/build/WasiApp.CoreCLR.targets:24

• This UsingTask declaration omits TaskFactory/Condition that are used elsewhere for WasmAppBuilder tasks. Without TaskHostFactory, MSBuild may attempt to load the task in-proc under .NET Framework MSBuild, which is fragile and can break depending on how WasmAppBuilderTasksAssemblyPath is resolved.

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

[jkotas]

Whether a type can be handed to native code as-is.

This is not a definition of blittable type. The definition of blittable type is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/blittable-and-non-blittable-types . It is mostly concerned with whether the payload can be marshalled by pinning.

Also, TypeDesc alone is not sufficient to determine the unmanaged type that the type is going to marshalled into. [MarshalAs] and other interop attributes can alter the type that the type is going to be marshalled into.

To do this correctly, we would have to call Marshaller.IsMarshallingRequired or a more lenient custom method like that.

I am wondering what it would take to require DisableRuntimeMarshalling on wasm so that we do not have to deal with this. It would allow us to strip quite a bit of runtime code that deals with built-in interop marshalling.

[radekdoulik]

I have updated the comment and added WASM-TODO for the rest. I hope we can look into it as follow up?

[jkotas]

I have missed that the IsBlittable check does not cover regular PInvokes - see my other comment.

For this PR, I would drop the IsBlittalble check completel. It is not correct. Instead, instead just print a warning when we encounter PInvoke in a module without DisableRuntimeMarshalling and attached TODO to that.

[jkotas]

Suggested change

	Generation does not load the JIT, so a host-targeting crossgen2 answers wasm questions
	correctly. In the repo it comes from the build output; outside it, from the crossgen2 pack
	In the repo it comes from the build output; outside it, from the crossgen2 pack

Can we drop the note about generation not loading the JIT? It is irrelevant for the build scripts. Also, even if crossgen2 did end up loading the JIT for the generation, it would still work fine. crossgen2 is cross-targeting compiler and loads target specific JIT.

(Fix all places.)

[jkotas]

Could you please fix the remaining places as well?

[radekdoulik]

@maraf please review the build related parts

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (6)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:36

• Several members in PInvokeInfo have nullable-signature mismatches that are likely to warn under nullable annotations (and can become build-breaking if warnings are treated as errors): IEquatable<T>.Equals should accept a nullable argument, and Equals(object) should accept object?. Adjust signatures to match the interfaces/overrides and keep the null checks.

This issue also appears on line 114 of the same file.

 public bool Equals(PInvokeInfo other)
=> other is not null && string.Equals(Identity, other.Identity, StringComparison.Ordinal);
public override bool Equals(object obj) => Equals(obj as PInvokeInfo);
public override int GetHashCode() => Identity.GetHashCode(StringComparison.Ordinal);

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:112

• PInvokeCallback has non-nullable auto-properties (EntryPoint, EntrySymbol) that are not definitely assigned on all constructor paths (e.g., when [UnmanagedCallersOnly] has no EntryPoint named argument). This is both a correctness signal (these values are genuinely optional) and a source of nullable warnings. Make them nullable to reflect semantics and avoid uninitialized non-nullable members.

 public MethodSignature Parameters => Method.Signature;
public string EntryPoint { get; }
public EcmaMethod Method { get; }
public string EntrySymbol { get; set; }
public string AssemblyName { get; }
public string TypeName { get; }
public string TypeFullName { get; }
public string Namespace { get; }
public string MethodName { get; }
public TypeDesc ReturnType { get; }
public bool IsExport { get; }
public bool IsVoid { get; }
public uint Token { get; }
public string Key { get; }
}

src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PortableCallHelpersGenerator.cs:22

• PortableCallHelpersGeneratorOptions declares non-nullable init-only string properties without defaults. With nullable enabled, this is typically a CS8618 warning (non-nullable property must contain a non-null value when exiting constructor). Provide defaults (and rely on the existing validation in Run) so the type is warning-free.

 public sealed class PortableCallHelpersGeneratorOptions
{
public string OutputDirectory { get; init; }
public IReadOnlyList<string> PInvokeModules { get; init; } = [];
public string TargetOS { get; init; }
}

src/coreclr/tools/aot/crossgen2/Program.cs:52

• _generatePortableCallHelpers can be null when the option is not specified, but it's stored in a non-nullable string field and then compared to null. This will trigger nullable warnings under <Nullable>enable</Nullable> and is inconsistent with the subsequent null checks. Make the field nullable (string?).

 private readonly string _outputFilePath;
private readonly string _generatePortableCallHelpers;
public Program(Crossgen2RootCommand command)
{
_command = command;
_inputBubble = Get(command.InputBubble);
_singleFileCompilation = Get(command.SingleFileCompilation);
_outNearInput = Get(command.OutNearInput);
_outputFilePath = Get(command.OutputFilePath);
_generatePortableCallHelpers = Get(command.GeneratePortableCallHelpers);

src/tasks/WasmAppBuilder/FilterManagedAssemblies.cs:35

• Assemblies is declared nullable but is dereferenced unconditionally (Assemblies.Length, foreach (… in Assemblies)). With <Nullable>enable</Nullable> in this project, this will produce nullable warnings (often treated as errors) and also makes the task less robust if invoked incorrectly. Add an early null check (or use Assemblies! after validating) before using it.
  src/coreclr/tools/aot/ILCompiler.ReadyToRun/PortableCallHelpers/PInvokeCollector.cs:121
• IComparer<T>.Compare is annotated to accept nullable arguments; using non-nullable parameters here can produce nullability mismatch warnings (CS8767) under nullable enabled builds. Update the signature to accept nullable and handle nulls explicitly.

 internal sealed class PInvokeCallbackComparer : IComparer<PInvokeCallback>
{
public int Compare(PInvokeCallback x, PInvokeCallback y)
{
int compare = string.Compare(x.Key, y.Key, StringComparison.Ordinal);
return compare != 0 ? compare : x.Token.CompareTo(y.Token);
}
}

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

[jkotas]

Suggested change

	if(HasAssemblyDisableRuntimeMarshallingAttribute((EcmaAssembly)method.Module))
	returntrue;
	// No DisableRuntimeMarshalling attribute, so check if the params/ret-type are blittable
	//
	// WASM-TODO: asking about the type alone is not enough to know what it marshals into,
	// because [MarshalAs] and the other interop attributes on a parameter can change that.
	// Marshaller.IsMarshallingRequired, or a more lenient variant of it, is the question to
	// ask instead. Requiring DisableRuntimeMarshalling on wasm would retire the check
	// altogether, and let the runtime drop its built-in marshalling code with it.
	MethodSignaturesignature=method.Signature;
	if(!signature.ReturnType.IsVoid&&!IsBlittable(signature.ReturnType))
	thrownewLogAsErrorException($"The return type '{signature.ReturnType}' of pinvoke callback method '{method}' needs to be blittable.");
	foreach(TypeDescparameterTypeinsignature)
	{
	if(!IsBlittable(parameterType))
	thrownewLogAsErrorException($"Parameter types of pinvoke callback method '{method}' needs to be blittable.");
	}
	returntrue;
	returnfalse;

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

[jkotas]

I have missed that the IsBlittable check is not done for regular PInvokes. Regular PInvokes is where it would matters.

[jkotas]

UnmanagedCallersOnly methods do not support any marshalling. They are unconditionally on the "disabled marshalling" plan.

Both Roslyn and runtime produce errors if somebody uses managed types in UnmanagedCallersOnly signatures, so I do not think we need to bother with error handling here. It should be fine to assume that UnmanagedCallersOnly signature is valid.

For example, Roslyn will produce "CS8894: Cannot use 'object' as a parameter type on a method attributed with 'UnmanagedCallersOnly'."

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/coreclr/vm/wasm/generate-coreclr-helpers.proj:126

• The response file written for crossgen2 uses unquoted paths for the output directory and scan assembly full paths. If the repo/artifacts path contains spaces, the response file parser can split these into multiple tokens and the generator invocation can fail or scan the wrong inputs.
  src/mono/browser/build/BrowserWasmApp.CoreCLR.targets:716
• The crossgen2 response file is populated with unquoted paths (output directory and managed assembly FullPath). If the project/intermediate path includes spaces, the response file parser will split these into multiple tokens, breaking --generate-portable-callhelpers and/or the input assembly list.
  src/mono/wasi/build/WasiApp.CoreCLR.targets:181
• The response file written for crossgen2 includes unquoted paths (output directory and managed assembly FullPath). If $(WasmAppDir) or the intermediate directory contains spaces, System.CommandLine response-file parsing can split these values and cause crossgen2 argument parsing failures.
  src/tests/Common/CLRTest.WasmCorerun.targets:343
• The response file lines written for crossgen2 include unquoted paths (output directory and managed assembly FullPath). If any of these paths contain spaces (common on Windows user profiles or custom checkout locations), System.CommandLine response-file parsing will split them into multiple tokens and crossgen2 will mis-parse the arguments.

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

[jkotas]

Suggested change

	if(!method.HasCustomAttribute("System.Runtime.InteropServices","UnmanagedCallersOnlyAttribute"))
	if(!method.IsUnmanagedCallersOnly)

[jkotas]

Suggested change

	/// <summary>
	/// Matches an attribute by its simple name in any namespace, for attributes that are
	/// declared by user code rather than by the framework.
	/// </summary>
	privatestaticboolHasAttributeByName(EcmaMethodmethod,stringattributeName)
	{
	MetadataReaderreader=method.MetadataReader;
	foreach(CustomAttributeHandlehandleinreader.GetMethodDefinition(method.Handle).GetCustomAttributes())
	{
	if(reader.GetAttributeNamespaceAndName(handle,out_,outStringHandlename)
	&&reader.StringComparer.Equals(name,attributeName))
	{
	returntrue;
	}
	}
	returnfalse;
	}

There is existing HasCustomAttribute method. Can we used that instead?

[jkotas]

Ah ok, this is matching attribute without namespace to check for MonoPInvokeCallbackAttribute . Can we just get rid of all of it? If somebody has a method with MonoPInvokeCallbackAttribute, they are going to find out very quickly when testing their app that it does not work - CoreCLR produces predictable exception in that case.

[jkotas]

Suggested change

	privateboolDoesMethodHaveCallbacks(EcmaMethodmethod)
	privateboolIsMethodCallback(EcmaMethodmethod)

Nit: The method itself is (exactly-one) callback. "DoesMethodHaveCallbacks" does not match what this does.

[pavelsavara]

Is this duplicate of #133040 ?