Skip to content

[wasm] Bump chrome for testing - linux: 118.0.5993.117, windows: 119.0.6045.59 - #2

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
update-chrome-version-6679964994
Open

[wasm] Bump chrome for testing - linux: 118.0.5993.117, windows: 119.0.6045.59#2
github-actions[bot] wants to merge 1 commit into
mainfrom
update-chrome-version-6679964994

Conversation

@github-actions

Copy link
Copy Markdown

No description provided.

AndyAyersMS pushed a commit that referenced this pull request Nov 14, 2023
…tnet#90436)

* Enable IL trim for WASM by default

* Make ILStrip available for local build

* Make all calling another method go through the logic to see if it could call an AOT'ed version of it before trying to interp compile it

* Add back accidentally removed line of code

* Update test to accommodate IL trim with WASM AOT

* Move jit_call_can_be_supported to mini-runtime, so it doesn't depends on the value of mono_use_interpreter

* Update var name

* Attempt to fix rebuild test failures

* Attempt to fix the file open issue with unicode on windows

* Attempt to fix unicode issue #2

* Enable g_fopen to have the capability of handling opening files with unicode name on all platforms

* Add comment

* Update comment

* Fix file indentation format

* Check if string contains non-ascii char

* Remove unused callback

* Remove redundant comment

* Update method name

* Fixed some method not found issues and remove the optimization for g_fopen

* Fix tailcall

* Disable tailcall optimization when calling a trimmed method

* Free method header

* Fix windows build error

* Free method header at the correct locatioin

* Fix the condition of skipping tailcall

* Fix test failure

* Move JIT/AOT call invoke away from MINT_CALL, as it is not needed there.

* Fix virtual tail call

* Address review feedback

* Put the trimmed assemblies in a new folder, output an updated list of assemblies and update _WasmAssembliesInternal with the new list

* Put trimmed assemblies in IntermediateOutputPath

* Remove TrimmedAssemblies

* Create trimmed assembly folder before the parallel run

* Try to fix the issue with missing item

* Fix parallelism issue

* Only start the trim when the assembly is newer than the output

* Add assembly item to the list, when

* Add some logging

* Fixed runtimeconfig.json file path issue and disabed failed tests

* Update parameter name

* Fix wasi build

* Use the correct parameter

* Fix runtime test failure

* WasmAppBuilder: runtimeconfig.json path can be null

* cleanup

* ILStrip: fix typo in id name

* Cleanup

* ILStrip: ensure output assemblies are in the same order as the input. This is required for incremental builds.

* more cleanup

* Re-enable disabled tests

* Change the default value for WasmStripILAfterAOT to false

* Fix the issue with changing the value of WasmStripILAfterAOT between incremental builds

* Move the location of file deleting

* Use WasmAssembliesFinal or ResolvedFileToPublish during publish in WasmSDK

* Copy metadata in AOT compiler and when creating WasmAssembliesToBundle from ResolvedFileToPublish

* Add _WasmSatelliteAssemblies to WasmAssembliesFinal

* Add a wasm template test

* Include all non-dll ResolvedFileToPublish for ComputeWasmPublishAssets

* Add a blazor template test

* Address review feedback

* Update src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTests.cs

Co-authored-by: Ankit Jain <radical@gmail.com>

* Update parameter name

* Update usage of parameter

* Revert EmccCompile change

* MonoAOTCompiler: revert rebuilding when WasmStripILAfterAOT value changes

* Compress -> GZipCompress, and cleanup

* rework the tests

- to support webcil case
- run blazor app
- add cases for the default setting, and the opposite
- cleanup

* ILStrip.cs: Emit a message about stripping to make it obvious to the user

* WasmApp.targets: update comment

* Change default value to false and update test

---------

Co-authored-by: Ankit Jain <radical@gmail.com>
Co-authored-by: Marek Fišera <mara@neptuo.com>
AndyAyersMS pushed a commit that referenced this pull request Dec 2, 2023
Fixes dotnet#95367.

Relevant part of the JitDump:

```
Using `if true` assertions from pred BB02
Assertions in: #1
fgMorphTree BB04, STMT00021 (before)
               [000070] DA---------                         *  STORE_LCL_VAR ubyte  V10 tmp9
               [000057] -----------                         \--*  CAST      int <- ubyte <- int
               [000006] -----------                            \--*  EQ        int
               [000004] -----------                               +--*  LCL_VAR   ref    V02 tmp1          (last use)
               [000055] H----------                               \--*  CNS_INT(h) ref     'Frozen EmptyPartition`1<Int32> object'

Assertion prop for index #1 in BB04:
               [000006] -----------                         *  EQ        int
GenTreeNode creates assertion:
               [000070] DA---+-----                         *  STORE_LCL_VAR ubyte  V10 tmp9
In BB04 New Local Constant Assertion: V10 == [0000000000000001], index = #2

fgMorphTree BB04, STMT00021 (after)
               [000070] DA---+-----                         *  STORE_LCL_VAR ubyte  V10 tmp9
               [000055] H----+-----                         \--*  CNS_INT(h) int
```

The JitDump is unfinished because the compiler crashes when trying to dump the last line. Clearly, the `CNS_INT` is no longer a handle at that point because we just bashed it to a constant 1.
AndyAyersMS pushed a commit that referenced this pull request Jan 17, 2024
…tnet#95292)

* Add IndentText json option

* Add IndentText for json source generator

* Add tests

* IndentText must be non-nullable

* Improve performance

* Add extra tests

* Cleanup

* Apply suggestions from code review

Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>

* Fixes following code review

* Fixes following code review #2

* Add tests for invalid characters

* Handle RawIndent length

* Move all to RawIndentation

* Update documentation

* Additional fixes from code review

* Move to the new API

* Extra fixes and enhancements

* Fixes from code review

* Avoid introducing extra fields in JsonWriterOptions

* Fix OOM error

* Use bitwise logic for IndentedOrNotSkipValidation

* Cache indentation options in Utf8JsonWriter

* Add missing test around indentation options

* New fixes from code review

* Update src/libraries/System.Text.Json/src/System/Text/Json/Writer/Utf8JsonWriter.cs

* Add test to check default values of the JsonWriterOptions properties

* Fix comment

---------

Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
AndyAyersMS pushed a commit that referenced this pull request Jul 16, 2024
* [wasm] Bump emscripten to 3.1.56

* Replace Module.asm with Module.wasmExports

Module.asm was removed, use wasmExports instead.
Context: emscripten-core/emscripten#19816

* Updates for .native.worker.js -> mjs rename

Context: emscripten-core/emscripten#21041

* Update deps

* Add general testing feed

* Update mode deps

* Update path

* Use current python packages for now, we don't have newer ones

The current names 3.1.34 are new enough

* Keep using llvm 16 for runtime and aot compiler

* Add -Wno-pre-c11-compat only for browser

* Temporarily disable version checks to get further

* Temporarily disable version checks to get further #2

* Disable -Wunused-command-line-argument

* Update emsdk deps

* Update icu dependency

* Revert "Temporarily disable version checks to get further #2"

This reverts commit 3f8834f.

* Revert "Temporarily disable version checks to get further"

This reverts commit fe1e5c6.

* Fix emsdk check

We use system python on osx too

* Workaround wasm-opt crash

* Workaround wasm-opt crash

* Workaround wasm-opt crash

* Fix WBT test

* Feedback

* Update ICU dependency

* Update emscripten deps

* Revert "Workaround wasm-opt crash"

This reverts commit 200cf3b.

* Revert "Workaround wasm-opt crash"

This reverts commit 4530edf.

* Revert "Workaround wasm-opt crash"

This reverts commit 3593c41.

* Increase tests timeout

* Show test progress

* Increase MT library tests timeout

* Disable WBT tests with SkiaSharp

* Increase helix tests timeout on browser

* Increase WBT timeout

* Increase initial heap sizes

* Fix mono_wasm_load_runtime cwrap signature

Fixes: `Uncaught ExitStatus: Assertion failed: stringToUTF8Array expects a string (got number)`

* Enable XunitShowProgress for threading tasks tests

* Try to reduce number of parallel AOT compilations

To check whether it will improve memory issues on CI

* Use new docker image for helix/windows tests

* Revert "Try to reduce number of parallel AOT compilations"

This reverts commit 5d9a6d2.

* Reduce the timeouts

* Reduce intitial heap size

* use active issues for MT

* Remove testing channel from nuget config, update deps

* Update emsdk and icu dependencies

---------

Co-authored-by: Larry Ewing <lewing@microsoft.com>
Co-authored-by: pavelsavara <pavel.savara@gmail.com>
AndyAyersMS pushed a commit that referenced this pull request Sep 7, 2024
* bug #1: don't allow for values out of the SerializationRecordType enum range

* bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type

* bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use)

* bug #4: document the fact that IOException can be thrown

* bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails

* bug #6: 0 and 17 are illegal values for PrimitiveType enum

* bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)
AndyAyersMS pushed a commit that referenced this pull request Mar 24, 2026
…otnet#124642)

## Summary

Fixes dotnet#123621

When a constant-folded operand appears **after** a non-constant operand
in a short-circuit `&&` expression (e.g., `v == 2 && Environment.NewLine
!= "\r\n"`), callee inlining can leave dead local stores in the return
block. The `isReturnBool` lambda in `fgFoldCondToReturnBlock` required
`hasSingleStmt()`, which caused the optimization to bail out when these
dead stores were present, resulting in suboptimal branching codegen.

### Changes

- **`src/coreclr/jit/optimizebools.cpp`**: Relax the `hasSingleStmt()`
constraint in `isReturnBool` to allow preceding statements as long as
they have no globally visible side effects
(`GTF_GLOBALLY_VISIBLE_SIDE_EFFECTS`). This enables
`fgFoldCondToReturnBlock` to fold the conditional into a branchless
return even when dead local stores from inlining remain in the block.

### Before (ARM64, `Inline_After`)
```asm
      cmp     w0, #2
      bne     G_M4495_IG04
      mov     w0, #1
      ret
G_M4495_IG04:
      mov     w0, #0
      ret
```

### After (ARM64, `Inline_After`)
```asm
      cmp     w0, #2
      cset    x0, eq
      ret
```

## Test plan

- [x] Added regression test `Runtime_123621` covering the original issue
pattern
- [x] Verified `Hoisted`, `Inline_Before`, and `Inline_After` all
produce identical branchless codegen (`cset` on ARM64)
- [x] Verified existing `DevDiv_168744` regression test still passes
- [x] Verified side-effect-ful blocks are correctly excluded from the
optimization
AndyAyersMS pushed a commit that referenced this pull request May 14, 2026
…128163)

> [!NOTE]
> This PR was authored with assistance from GitHub Copilot.

Fixes dotnet#128044.

## Problem

createdump SIGSEGVs on Linux when generating a Heap-type minidump for a
process running interpreted code. The crash reproduces locally with the
`InterpreterStack` DumpTests debuggee and matches the CI failure that
prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary
workaround.

The faulting backtrace is:

```
#0  Thread::IsAddressInStack    threads.cpp:6741
#1  Thread::EnumMemoryRegionsWorker  threads.cpp:6909 (calls IsAddressInStack(currentSP))
#2  Thread::EnumMemoryRegions        threads.cpp
#3  ThreadStore::EnumMemoryRegions
#4  ClrDataAccess::EnumMemDumpAllThreadsStack
#5  ClrDataAccess::EnumMemoryRegionsWorkerHeap   (HEAP2-only path)
```

## Root cause

`Thread::m_pInterpThreadContext` was declared as a raw
`InterpThreadContext *`. In non-DAC code that's a normal host pointer,
but in
DAC mode the field's value is a target-process address. When
`IsAddressInStack` (a DAC-callable helper) dereferenced
`m_pInterpThreadContext->pStackStart` it read from a target-process
address
as if it were a host address, which faults inside createdump.

## Fix

Change the field type to `PTR_InterpThreadContext` (DPTR), matching the
treatment of other Thread fields like `m_pFrame`. In non-DAC builds
`DPTR(T)` is just `T*`, so there is no overhead or behavior change. In
DAC
builds the read goes through `__DPtr<T>` and marshals correctly from the
target.

Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the
`InterpreterStack` DumpTests debuggee so the Heap path that originally
failed is exercised again.

## Validation

Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump
mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`)
running the `InterpreterStack` debuggee. With this fix applied,
createdump
produces a complete Heap dump (~74 MB) instead of crashing.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
AndyAyersMS added a commit that referenced this pull request Jun 9, 2026
In Compiler::optNarrowTree, the GT_CAST case bails when
`tree->CastToType() != srct`. For unsigned widening casts produced by
the C# compiler (e.g. an implicit uint->long widening synthesized when
unary minus promotes uint to long), CastToType is TYP_ULONG even though
tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing,
even though both representations are bit-identical and the subsequent
transformation (rewriting an int<->long cast as an int<->int identity)
is correct for either signedness.

The user-visible effect was that patterns like

    (uint)-(a >> 20)
    (uint)-(a << 2)
    (uint)~(ulong)(a >> 3)

failed to fold the redundant widening cast left over after morph pushes
the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast
serialized as a no-op `mov w0, w0` between the shift and the negate,
preventing arm64 lowering from containing the shift into the negate:

    lsr w0, w0, dotnet#20      ; was 3 instructions
    mov w0, w0
    neg w0, w0

Compare with the equivalent NegLSL pattern (no intermediate cast),
which already produces `neg w0, w0, LSL #2`.

Switching the comparison to `genActualType(CastToType()) != genActualType(srct)`
lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is
narrowed away, lowering sees a direct NEG/MVN over the shift, and
codegen emits the single-instruction shifted form:

    neg w0, w0, LSR dotnet#20
    neg w0, w0, LSL #2
    mvn w0, w0, LSR #3

The companion `tree->TypeIs(TYP_LONG)` check is also replaced with
`genActualType(tree) == TYP_LONG` for consistency; the two are
functionally equivalent for well-formed IR (cast nodes' TypeGet always
returns the actual type, never the unsigned variant).

Fixes dotnet#111888

Test updates in src/tests/JIT/opt/InstructionCombining/:
- Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg`
  buggy codegen as expected, updated to expect the single-instruction
  shifted form.
- Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast
  round trip) as expected; the fix eliminates the cast entirely so the
  method body has no instructions. Changed to ARM64-NOT: mov to assert
  absence of the redundant move.
- Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN.

Co-authored-by: Andy Ayers <andya@microsoft.com>
AndyAyersMS added a commit that referenced this pull request Jun 10, 2026
In Compiler::optNarrowTree, the GT_CAST case bails when
`tree->CastToType() != srct`. For unsigned widening casts produced by
the C# compiler (e.g. an implicit uint->long widening synthesized when
unary minus promotes uint to long), CastToType is TYP_ULONG even though
tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing,
even though both representations are bit-identical and the subsequent
transformation (rewriting an int<->long cast as an int<->int identity)
is correct for either signedness.

The user-visible effect was that patterns like

    (uint)-(a >> 20)
    (uint)-(a << 2)
    (uint)~(ulong)(a >> 3)

failed to fold the redundant widening cast left over after morph pushes
the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast
serialized as a no-op `mov w0, w0` between the shift and the negate,
preventing arm64 lowering from containing the shift into the negate:

    lsr w0, w0, dotnet#20      ; was 3 instructions
    mov w0, w0
    neg w0, w0

Compare with the equivalent NegLSL pattern (no intermediate cast),
which already produces `neg w0, w0, LSL #2`.

Switching the comparison to `genActualType(CastToType()) != genActualType(srct)`
lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is
narrowed away, lowering sees a direct NEG/MVN over the shift, and
codegen emits the single-instruction shifted form:

    neg w0, w0, LSR dotnet#20
    neg w0, w0, LSL #2
    mvn w0, w0, LSR #3

The companion `tree->TypeIs(TYP_LONG)` check is also replaced with
`genActualType(tree) == TYP_LONG` for consistency; the two are
functionally equivalent for well-formed IR (cast nodes' TypeGet always
returns the actual type, never the unsigned variant).

Fixes dotnet#111888

Test updates in src/tests/JIT/opt/InstructionCombining/:
- Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg`
  buggy codegen as expected, updated to expect the single-instruction
  shifted form.
- Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast
  round trip) as expected; the fix eliminates the cast entirely so the
  method body has no instructions. Changed to ARM64-NOT: mov to assert
  absence of the redundant move.
- Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN.

Co-authored-by: Andy Ayers <andya@microsoft.com>
AndyAyersMS pushed a commit that referenced this pull request Sep 4, 2026
…stem (dotnet#131877)

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 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 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.

## The change

crossgen2 gains `--generate-portable-callhelpers <dir>`, which writes
the three C++ call-helper files directly. It sets up its type system 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 deleted rather than adapted:
`ManagedToNativeGenerator`, `PInvokeCollector`, `PInvokeTableGenerator`,
`SignatureMapper`, `InternalCallSignatureCollector`,
`InterpToNativeGenerator`. `_CoreCLRGenerateManagedToNative` keeps its
name and position in the target graph; its final step changes from
`<UsingTask>` to `<Exec>`. The regeneration scripts move next to their
output under `src/coreclr/vm/wasm/` and drive
`generate-coreclr-helpers.proj`. Mono's generator is untouched.

**−2269 lines under `src/tasks`, +1541 under
`ILCompiler.ReadyToRun/PortableCallHelpers`.** 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. 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. Per [review
feedback](dotnet#131877)
nothing in this functionality is named after wasm. Symbols shared by the
runtime and the generated tables were renamed on both sides at once:

| before | after |
|---|---|
| `StringToWasmSigThunk` | `StringToPortableSigThunk` |
| `g_wasmThunks[Count]` | `g_portableCallHelperThunks[Count]` |
| `wasm_ret_S<n>` | `portable_callhelper_ret_S<n>` |

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

Three paths, tried in order:

- **Override** — `$(PortableCallHelpersGeneratorPath)`, which must name
a crossgen2 executable.
- **In repo** — `$(Crossgen2InBuildDir)`; crossgen2 is built
unconditionally by the `clr` subset.
- **Out of repo** — the `wasm-tools` workload declares the existing
`Microsoft.NETCore.App.Crossgen2.<host-rid>` pack, whose `Sdk/Sdk.props`
defines `$(Crossgen2ToolPath)`. ~12.5 MB.

The SDK resolves this pack only when `PublishReadyToRun` is set, which
wasm CoreCLR apps never set — hence the workload. dotnet/sdk#56119
proposes acquiring it directly instead, which would let the workload
entry go. If none of the three resolve, the targets error rather than
passing an empty path down.

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.

The workload-testing legs do not set `$(BuildHostTools)`, so nothing
produced a crossgen2 pack for their local package feed. (The perf
browser-wasm leg does produce one, but only because it opts in —
dotnet#133143.) `Microsoft.NETCore.App.Crossgen2.Host.sfxproj` pins the RID to
the build host, and is now built by the CoreCLR browser-wasm leg behind
`$(BuildCrossgen2HostPackForWorkloadTesting)`, guarded on
`$(BuildHostTools)` being unset so the two paths can never emit the same
package id twice. The official build is untouched — it already publishes
this pack from the host platform legs.

## Behaviour changes

**`WASM0066` is removed.** The old task warned for every `DllImport`
whose module did not resolve to a linked-in native library — a
CoreCLR-only divergence that fires on ordinary cross-platform code never
executed on wasm (dotnet#131874 reports ten from SkiaSharp alone on a shipped
Preview 7 SDK). In-tree it had already accumulated two `NoWarn`
suppressions and a `WarnOnUnresolvedPInvokeModules=false`; all three go,
along with the `--no-warn-unresolved-directpinvoke` opt-out that existed
only to silence it. An unresolved module is not knowably wrong at build
time: `callhelpers_pinvoke_override` returns `nullptr` on a miss, so a
call that actually happens throws `DllNotFoundException` naming the
module, as on every other platform. Dropping a warning is strictly
loosening.

**`WASM0065` is added, as a message.** Per module, when it declares
P/Invokes without `[assembly: DisableRuntimeMarshalling]`, since the
generated helpers assume signatures cross unmarshalled. A message rather
than a warning: it reports something the app author often cannot fix,
and as a warning it would fail `-warnaserror` builds. Four fire across
the 181 framework assemblies.

**Exported callbacks with an ambiguous name are rejected.** An export
wrapper resolves its `MethodDesc` through
`LookupUnmanagedCallersOnlyMethodByName`, which takes the first
`[UnmanagedCallersOnly]` method of matching name and compares no
signature — so two exported overloads resolve to the same method and one
wrapper calls it with the wrong arguments. Everything the generator
controls carries the arity, so the existing duplicate-key and
duplicate-symbol checks both pass. Generation now fails instead, naming
both signatures. Only exports: a non-exported callback is found by the
arity-aware key and never reaches the name lookup.

## Known limitations

- **wasi has no 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.
- **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, so nothing exercises this. The old generator
rejected such callbacks with `WASM0067`; this one accepts them, so user
code would get a bad thunk rather than a diagnostic.
- **`'V'` (v128) has no case in the C++ emission helpers.**
Pre-existing; fails loudly.
- **Multi-slot types (`Int128`, `Vector256`, …) are rejected at the
thunk emitter** rather than at the interop boundary, so the diagnostic
differs from the old `WASM0068`. Still a clean `crossgen2 : error :`
with exit 1. No such P/Invoke exists today.
- Does not re-enable the tests disabled in dotnet#131811 (dotnet#133187), and does
not address gaps #3#7 there.

## Verification

- **Regeneration reproduces the committed helpers byte for byte**, apart
from the rename above, with zero
`WASM0001`/`WASM0060`/`WASM0061`/`WASM0062` warnings across a full
CoreLib+libraries scan. (The checked-in P/Invoke table is already
slightly stale against `main` independently of this PR; that drift is
left alone.)
- `WasmArgumentLayoutTests` goes from 17 to 22 test methods. The two
covering the rejection above were checked against a disabled check, so
they test it rather than agree with it.
- `clr+libs` builds clean for `browser` and `wasi`; `WasmAppBuilder`
still builds for both `net11.0` and `net472`.
- Both flavors build end to end from the in-tree samples, with
per-architecture native payloads, a non-PE file and duplicate-culture
satellites injected into the bundle.
- The renamed runtime contract was checked by building:
`libcoreclr_static.a` exports `g_portableCallHelperThunks` and no
`g_wasmThunks`, and the browser sample links its generated tables
against it.

Contributes to dotnet#131811, closing blocking gap #1 and the struct half of
gap #2: a 3-int and a 5-double struct in `[UnmanagedFunctionPointer]`
signatures now resolve to `vS12` / `S12i` / `vS40i`, where all three
previously threw `NotSupportedException`.

> [!NOTE]
> This pull request description was drafted with the help of GitHub
Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Copilot-Session: f6d6e5a4-5b25-4198-b42d-d5b2dc781f47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants