[browser][CoreCLR] Enable non-AOT WBT relinking and rebuild coverage

[radekdoulik]

CoreCLR browser-wasm supports per-app native relinking, but several Wasm.Build.Tests still exclude it through coarse Mono-only categories. Enable the verified non-AOT cases in 23 methods, while preserving the existing Mono test inputs and leaving product code unchanged.

The enabled coverage includes P/Invoke ABI and platform filtering, native-library names, invariant globalization/timezone, the Bug49588 relinking regression, template marshal-IL generation, main arguments, satellite resources, Blazor clean/DllImport/publish/Razor-library scenarios, and incremental native rebuilds.

Implementation

• Narrow Mono-only categories and use runtime-aware theory data without removing existing Mono/AOT rows. Keep aot: true variants out of this CoreCLR port: RunAOTCompilation does not currently select managed AOT on CoreCLR, so adding those inputs would largely duplicate coverage. CoreCLR's separate PublishReadyToRun tests are unchanged.
• Track CoreCLR's portable call-helper sources, objects, response files, and symbol map rather than Mono's P/Invoke tables and driver objects. Require the generated files to exist before comparing rebuild statistics.
• Check runtime-specific no-op, source-change, compiler/linker flag, and optimization behavior. Verify recompilation directly where object-byte equality across optimization levels is incidental.
• Reuse the existing minimal JavaScript entry point for the CoreCLR marshal-IL template case, whose program has no JavaScript exports. Preserve Mono's existing entry point.

Coverage

Measure	CoreCLR	Mono
Rows in the 23 methods, local configuration	84 newly enabled	102 unchanged
Rows in the 23 methods, CI configuration	54 newly enabled per OS	72 unchanged
Generated workload test classes	34 -> 45	52 unchanged

The CI row counts were verified from a test assembly built with ContinuousIntegrationBuild=true. Local builds include additional implicit Debug rows. These numbers describe test selection, not a new CI execution.

All 84 newly enabled CoreCLR rows passed locally. Native linking was observed in 70 rows; the remaining 14 intentionally cover no-relink variants within mixed test methods.

Remaining exclusions

NativeRelinkFailsWithInvariant and BuildWithUndefinedNativeSymbol retain method-level Mono gates. Other Mono-only AOT/generator/profiler cases, auto-layout diagnostics, the Windows-specific temp-path test, and the memory test are unchanged.

ReferenceNewAssemblyRebuildTest.ReferenceNewAssembly also remains Mono-only. Its four attempted CoreCLR rows exposed an incremental trimmed-publish bug: System.Text.RegularExpressions.dll is produced by the linker but omitted from WebCIL/published assets and boot configuration because build candidates were restricted using the previous trimmed closure. This needs a separate product fix; the test was not weakened by cleaning between publishes or pre-rooting the assembly.

Validation

Validated on macOS/arm64 with Chrome 154.0.8037.58, SDK 12.0.100-alpha.1.26471.108, and matching locally built 12.0.0-dev runtime, Crossgen2, and workload packages.

• CoreCLR: 23 methods, 84 passed, 0 failed, 0 skipped. XML counters were cross-checked against individual test names and expected theory rows.
• Mono: 3 focused methods, 12 passed, 0 failed, 0 skipped. These cover Blazor publish, native no-op rebuilds, and optimization changes, including three actual AOT-compiling rows. The complete Mono input matrix remains unchanged.
• After review corrections, all 12 affected CoreCLR rows and all 12 focused Mono rows passed again.
• CoreCLR local/CI-mode and Mono local test builds passed with zero warnings/errors. Generated class lists and data providers confirm the intended selection. git diff --check passed.

The existing Mono Blazor publish row labeled aot: true does not actually forward AOT to publish; this pre-existing behavior is preserved, not counted as an AOT compilation.

Local build and test commands

Build the browser runtime and required host Crossgen2 package:

export PATH="/opt/homebrew/bin:$PATH"
export DOTNET_WASM_TOOL_CACHE_DIR="$PWD/.dotnet/wasm-tools"

./build.sh -os browser -c Release -subset clr+libs
./build.sh -os browser -c Release -subset packs.product \
  -p:RuntimeFlavor=CoreCLR -p:BuildCrossgen2HostPackForWorkloadTesting=true \
  -p:TestAssemblies=false -p:InstallWorkloadForTesting=false

After preparing and installing the matching local workload packages, run a selected method through the repository's WBT entry point:

make -C src/mono/browser run-build-tests CONFIG=Release \
  MSBUILD_ARGS="-p:RuntimeFlavor=CoreCLR -p:TestUsingWorkloads=true \
  -p:InstallWorkloadForTesting=false -p:WasmSkipMissingRuntimePackBuild=true \
  -p:XUnitMethodName=Wasm.Build.Tests.PInvokeTableGeneratorTests.EnsureWasmAbiRulesAreFollowedInInterpreter"

That method selected zero rows before enablement and passed both Debug/Release rows afterward. The full enabled set used the same generated runner, selecting exact methods with RSP_FILE="-method <fully-qualified-method> -parallel none" in separate processes to bound disk usage.

CI selection was checked by rebuilding with -p:ContinuousIntegrationBuild=true -p:ArchiveTests=false -p:InstallWorkloadForTesting=false and evaluating the compiled data providers.

Linux/Windows behavioral execution and the full Mono/no-WebCIL matrix were not rerun locally. No CI was triggered during local validation.

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[lewing]

Looks good, one question