[browser] More Wasm.Build.Tests on CoreCLR by maraf · Pull Request #127281 · dotnet/runtime

maraf · 2026-04-22T15:30:52Z

Note

This PR description was AI-generated (GitHub Copilot CLI).

Follow-up to #127073. Now that WASM templates install and native relink work on CoreCLR in Wasm.Build.Tests (WBT), enable the non-AOT tests that were previously excluded by the class-level [TestCategory("native")] trait filter.

What changes

src/mono/wasm/Wasm.Build.Tests/Wasm.Build.Tests.csproj excludes category=native on CoreCLR:

<_XUnitTraitArg Condition="'$(RuntimeFlavor)' == 'CoreCLR'">-notrait category=native -notrait category=mono -notrait category=workload</_XUnitTraitArg>

xunit merges class-level and method-level traits, so moving native to a sub-category (e.g. native-coreclr) at method level does not help — the class-level native still causes exclusion. The fix is to remove the class-level tag and re-apply native only on the AOT-only methods.

File	Change
`NativeBuildTests.cs`	Remove class tag. Method-tag `AOTNotSupportedWithNoTrimming`, `IntermediateBitcodeToObjectFilesAreNotLLVMIR`, `NativeBuildIsRequired` (all AOT-only). Non-AOT methods (`SimpleNativeBuild`, `ZipArchiveInteropTest`) now run on CoreCLR.
`DllImportTests.cs`	Remove class tag. All methods are non-AOT — all run on CoreCLR.
`PInvokeTableGeneratorTests.cs`	Remove class tag. Method-tag `EnsureWasmAbiRulesAreFollowedInAOT`, `EnsureComInteropCompilesInAOT`.
`NativeLibraryTests.cs`	Remove class tag. Split the four theories that had both `[BuildAndRun(aot:false)]` and `[BuildAndRun(aot:true,…)]` into a non-AOT method and an `_AOT` method tagged `native` (they delegate to a shared `…Core` helper). The pre-existing `[ActiveIssue(#103566)]` on `ProjectUsingSkiaSharp` is applied to both halves.

Splitting (rather than runtime-skip) keeps test reporting honest: AOT-on-CoreCLR shows up as "excluded by filter" instead of a false pass.

Not in scope: other [TestCategory("native")] classes in WBT (BuildPublishTests, NativeRebuildTests/*, WasmSIMDTests, IcuTests, SatelliteAssembliesTests, …). Those often encode reasons beyond "class-level native is too broad" and are left for a follow-up.

Validation

Local build: ./dotnet.sh build src/mono/wasm/Wasm.Build.Tests/Wasm.Build.Tests.csproj -c Release /p:TargetOS=browser /p:RuntimeFlavor=CoreCLR /p:Scenario=BuildWasmApps → 0W/0E.
Helix end-to-end validation: this PR's CI.

dotnet-policy-service · 2026-04-22T15:44:43Z

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

Remove class-level [TestCategory("native")] from NativeBuildTests, NativeLibraryTests, PInvokeTableGeneratorTests, and DllImportTests so non-AOT methods pass the CoreCLR xunit filter (-notrait category=native). AOT-only methods get a method-level [TestCategory("native")] to keep them excluded on CoreCLR. NativeLibraryTests: four mixed theories (both aot=false and aot=true inline data) are split into a non-AOT theory and a separate AOT-only theory tagged 'native', because xunit trait filtering is per-method, not per-theory-row. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Change [TestCategory("native")] to [TestCategory("native-coreclr")] for tests that use native relink but should also run on CoreCLR: - IcuShardingTests: CustomIcuShard, AutomaticShardSelectionDependingOnEnvLocale - IcuShardingTests2: DefaultAvailableIcuShardsFromRuntimePack - IcuTests: FullIcuFromRuntimePackWithInvariant, FullIcuFromRuntimePackWithCustomIcu - InvariantGlobalizationTests: RelinkingWithoutAOT - MemoryTests: entire class (AllocateLargeHeapThenRepeatedlyInterop) CoreCLR always has native relink support, so these tests can run on both Mono and CoreCLR. The CoreCLR xunit filter excludes category=native but not category=native-coreclr. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Without these entries in BuildWasmAppsJobsListCoreCLR.txt, the test classes whose class-level [TestCategory("native")] was removed (or retagged to native-coreclr) in this PR would still not be scheduled as Helix work items for the CoreCLR BuildWasmApps scenario. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Copilot · 2026-04-24T10:10:09Z

    [Theory]
    [MemberData(nameof(FullIcuWithInvariantTestData), parameters: new object[] { Configuration.Release })]
-    [TestCategory("native")]
+    [TestCategory("native-coreclr")]
    public async Task FullIcuFromRuntimePackWithInvariant(Configuration config=Configuration.Release, bool aot=false, bool invariant=true, bool fullIcu=true, string testedLocales="Array.Empty<Locale>()") =>


Changing these theories to TestCategory("native-coreclr") makes them eligible to run under the CoreCLR lane filter (which only excludes category=native). However, the test data includes aot=true cases (boolOptions), and CoreCLR builds set <UseMonoRuntime>false</UseMonoRuntime>; AOT compilation is likely unsupported and will attempt to run anyway. Consider splitting into non-AOT methods (tagged native-coreclr) and AOT methods (keep category=native so they remain excluded on CoreCLR), or adjust the MemberData to exclude aot=true when BuildTestBase.IsCoreClrRuntime.

Copilot · 2026-04-24T10:10:09Z

    [Theory]
    [MemberData(nameof(IcuExpectedAndMissingCustomShardTestData), parameters: new object[] { Configuration.Release })]
-    [TestCategory("native")]
+    [TestCategory("native-coreclr")]
    public async Task CustomIcuShard(Configuration config, bool aot, string customIcuPath, string customLocales, bool onlyPredefinedCultures) =>


These tests use boolOptions for the aot parameter (so they generate AOT and non-AOT variants). Retagging them to native-coreclr will cause the AOT variants to run on the CoreCLR lane (since only category=native is excluded), which is likely unsupported for CoreCLR (UseMonoRuntime=false). Split/tag AOT variants as category=native (excluded on CoreCLR) or filter aot=true out for CoreCLR runs.

Copilot · 2026-04-24T10:10:10Z

    [Theory]
    [MemberData(nameof(IcuExpectedAndMissingShardFromRuntimePackTestData), parameters: new object[] { Configuration.Release })]
-    [TestCategory("native")]
+    [TestCategory("native-coreclr")]
    public async Task DefaultAvailableIcuShardsFromRuntimePack(Configuration config, bool aot, string shardName, string testedLocales) =>


This theory generates both aot=false and aot=true cases via boolOptions. After changing the category to native-coreclr, the AOT variants will no longer be excluded by the CoreCLR trait filter (-notrait category=native) and may run on CoreCLR where AOT is likely unsupported. Consider splitting/tagging AOT variants as category=native (excluded) or changing the data source to omit aot=true on CoreCLR.

Copilot · 2026-04-24T10:10:10Z

+[TestCategory("native-coreclr")]
 public class MemoryTests : WasmTemplateTestsBase


With the class retagged to native-coreclr, this test will start running in the CoreCLR lane. The build assertion currently uses ExpectSuccess: BuildTestBase.IsUsingWorkloads, but CoreCLR WBT runs with TestUsingWorkloads=false while native relink is now supported (emsdk is provisioned separately). That combination likely makes the test fail (it will expect the native build to fail even if it succeeds). Consider basing ExpectSuccess/execution on whether native builds are actually available (e.g., IsUsingWorkloads || IsCoreClrRuntime), or keep the test excluded until its expectations are updated.

Copilot · 2026-04-24T10:10:10Z

+Wasm.Build.Tests.IcuShardingTests
+Wasm.Build.Tests.IcuShardingTests2
+Wasm.Build.Tests.IcuTests
+Wasm.Build.Tests.InvariantGlobalizationTests
+Wasm.Build.Tests.MemoryTests


The PR description says additional TestCategory("native") classes like IcuTests are "not in scope" and left for follow-up, but this change adds Icu*, InvariantGlobalizationTests, and MemoryTests to the CoreCLR job list. Either update the PR description to reflect the expanded scope or remove these additions to match the stated intent.

EnsureWasmTemplatesInstalled placed .dotnet-cli-home next to the template nupkg (which on Linux Helix agents is under the read-only correlation payload), causing 'Read-only file system' / 'Access denied' errors for every test class that calls CreateWasmTemplateProject. Always use BuildEnvironment.TmpPath — the harness's writable scratch dir — instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EnsureWasmTemplatesInstalled set DOTNET_CLI_HOME to TmpPath/.dotnet-cli-home when running 'dotnet new install'. The subsequent 'dotnet new <template>' call goes through DotNetCommand(useDefaultArgs: false), which does not apply BuildEnvironment.EnvVars to the child process, so it inherited the Helix-set DOTNET_CLI_HOME (e.g. /root/helix/work/workitem/e/.dotnet). Two different DOTNET_CLI_HOME values mean two different template caches: the install lands in one, the lookup misses in the other, producing 'No templates or subcommands found matching: wasmbrowser' (exit 103) on every test class that calls CreateWasmTemplateProject. Prefer the inherited DOTNET_CLI_HOME so install and lookup share a cache; fall back to TmpPath only when not set (preserves the read-only-FS fix for environments without an inherited value). Reproduced locally with DOTNET_CLI_HOME=/tmp/helix-cli-home; templates were installed under wbt artifacts/.dotnet-cli-home but 'dotnet new' read from /tmp/helix-cli-home. After the fix, both paths share /tmp/helix-cli-home and 'dotnet new wasmbrowser' succeeds. Also adds [diag] Console.WriteLine entries logging both the install-time and invocation-time DOTNET_CLI_HOME so Helix work-item console logs make similar future regressions trivial to diagnose. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/mono/wasm/Wasm.Build.Tests/Templates/WasmTemplateTestsBase.cs:104

EnsureWasmTemplatesInstalled sets DOTNET_CLI_HOME only for the dotnet new install process. The subsequent dotnet new <template> invocation (via DotNetCommand(..., useDefaultArgs:false)) does not set DOTNET_CLI_HOME, so it may look in a different template cache when DOTNET_CLI_HOME is not already set in the test process environment (e.g., local runs). To make this robust, propagate the chosen dotnetCliHome to the dotnet new <template> command (or set it on the current process via Environment.SetEnvironmentVariable before invoking dotnet new).

        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
        // The template engine reads installed templates from this location; if it differs
        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
        // won't be found.
        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");

        using DotNetCommand cmd = new DotNetCommand(s_buildEnv, _testOutput, useDefaultArgs: false);
        CommandResult result = cmd.WithWorkingDirectory(_projectDir)
            .WithEnvironmentVariable("NUGET_PACKAGES", _nugetPackagesDir)
            .ExecuteWithCapturedOutput($"new {template.ToString().ToLower()} {extraArgs}")
            .EnsureSuccessful();

- Inline callhelpers.hpp / minipal/entrypoints.h declarations into the pre-included coreclr_compat.h and stop emitting #include lines for those headers from the CoreCLR generators, so pinvoke-table.cpp and wasm_m2n_invoke.g.cpp compile on Helix where the in-repo header paths do not exist. - Make BuildEnvironment.GetRuntimePackDir flavor-aware: on CoreCLR the runtime pack is Microsoft.NETCore.App.Runtime.<rid> (no .Mono. segment). - Mark DllImportTests.NativeLibraryWithVariadicFunctions as Mono-only; CoreCLR's PInvoke generator does not emit the expected varargs warning. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

….targets The previous attempt to generate coreclr_compat.h from a _CompatHeaderLines ItemGroup hit an MSBuild item-spec dedup/parsing issue: items whose Include value contained both `{...}` braces and embedded `%3B` semicolons were silently dropped from the output (verified with a minimal repro). That left the generated header with missing `StringToWasmSigThunk` and `ReverseThunkMapEntry` struct declarations, so pinvoke-table.cpp / wasm_m2n_invoke.g.cpp failed to compile on Helix. Replace the inline ItemGroup generation with a static coreclr_compat.h next to BrowserWasmApp.CoreCLR.targets and `-include` it via $(MSBuildThisFileDirectory). The file ships into the Helix correlation payload via the existing HelixCorrelationPayload Include="$(BrowserBuildTargetsDir)" mapping (sendtohelix-browser.targets), so it lands at correlation/build/wasm/coreclr_compat.h alongside the targets file. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ble-non-aot-tests # Conflicts: # src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs

Copilot

Pull request overview

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

+        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
+        // The template engine reads installed templates from this location; if it differs
+        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");
+


+                ? inheritedCliHome
+                : Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
            Directory.CreateDirectory(dotnetCliHome);
+            Console.WriteLine($"[diag] DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled: '{dotnetCliHome}' (process inherited: '{inheritedCliHome ?? "<unset>"}')");


+            if (t.IsValueType)
+            {
+                return CharToNameType('n');
+            }


PR dotnet#127438 split the browser+CoreCLR <LibrariesRuntimeFiles> element into two: one with the $(LibrariesSharedFrameworkDir)*.a glob, and a separate one for the host files. The Exclude= added in commit c0b0e63 for the three duplicate static libs (libminipal.a, libSystem.IO.Compression.Native.a, libz.a) stayed on the host element, where it had no effect because that element does not include any $(LibrariesSharedFrameworkDir) items. This caused NU5118 (duplicate file) to return for browser-wasm CoreCLR runtime pack builds: the three .a files are produced under both $(CoreCLRSharedFrameworkDir) and $(LibrariesSharedFrameworkDir), and both copies were getting packed. Move the Exclude= to the ItemGroup that actually contains the *.a glob so the duplicates are dropped again. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

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

+        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
+        // The template engine reads installed templates from this location; if it differs
+        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");
+


+                ? inheritedCliHome
+                : Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
            Directory.CreateDirectory(dotnetCliHome);
+            Console.WriteLine($"[diag] DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled: '{dotnetCliHome}' (process inherited: '{inheritedCliHome ?? "<unset>"}')");


CoreCLR-Wasm native relink fails with undefined GlobalizationNative_* symbols when InvariantGlobalization=true, because libSystem.Globalization.Native.a is not linked into the browser-wasm app but pinvoke-table.o still references the entry points. Gate the tests to Mono until CoreCLR-Wasm provides a stub for the System.Globalization.Native library. Tracked by dotnet#128219. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 4 comments.

+        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
+        // The template engine reads installed templates from this location; if it differs
+        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");
+


+                ? inheritedCliHome
+                : Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
            Directory.CreateDirectory(dotnetCliHome);
+            Console.WriteLine($"[diag] DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled: '{dotnetCliHome}' (process inherited: '{inheritedCliHome ?? "<unset>"}')");


+        [ConditionalTheory(typeof(BuildTestBase), nameof(IsMonoRuntime))]
        [MemberData(nameof(InvariantGlobalizationTestData), parameters: new object[] { /*aot*/ false })]
-        [TestCategory("native")]
+        [TestCategory("native-coreclr")]


+const { setModuleImports, getAssemblyExports, getConfig } = await dotnet
+    .withApplicationArguments("start")
+    .withDiagnosticTracing(true)
+    .withConfig({ forwardConsole: true, appendElementOnExit: true, logExitCode: true, exitOnUnhandledError: true })
+    .create();
+
+const config = getConfig();
+


Here I assume crossgen2 will replace the generator soon. Currently the generator is not able to handle fully the structures https://github.com/dotnet/runtime/blob/5d6e5b8246d731058b220c4b7b7be61809c7db49/src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs#L17-L27 In case we will need that sooner, we would need to calculate the size properly in the generator too.

Copilot

Pull request overview

Copilot reviewed 35 out of 35 changed files in this pull request and generated 5 comments.

+// Type stubs (Entry, DllImportEntry, minipal_resolve_dllimport, MethodDesc, ULONG,
+// logging macros) are provided via the compat header pre-included by
+// BrowserWasmApp.CoreCLR.targets, so this file does not include
+// <callhelpers.hpp> or <minipal/entrypoints.h> directly.



+            // Type stubs (Entry, DllImportEntry, minipal_resolve_dllimport, MethodDesc, ULONG,
+            // logging macros) are provided via the compat header pre-included by
+            // BrowserWasmApp.CoreCLR.targets, so this file does not include
+            // <callhelpers.hpp> or <minipal/entrypoints.h> directly.


+        ["PairStruct"] = 8, // Used by WBT tests
+        ["S"] = 8, // Used by WBT tests
        ["System.Runtime.CompilerServices.QCallModule"] = 8,
        ["System.Runtime.CompilerServices.QCallAssembly"] = 8,
        ["System.Runtime.CompilerServices.QCallTypeHandle"] = 8,
        ["System.GC+GCHeapHardLimitInfo"] = 64,
+        ["Test+S"] = 8, // Used by WBT tests


+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");


+Wasm.Build.Tests.IcuShardingTests
+Wasm.Build.Tests.IcuShardingTests2
+Wasm.Build.Tests.IcuTests
+Wasm.Build.Tests.InvariantGlobalizationTests
+Wasm.Build.Tests.MemoryTests


The CoreCLR product build (vm/wks CMake target) compiles these three files without force-including coreclr_compat.h, which is only pre-included by BrowserWasmApp.CoreCLR.targets during WasmAppBuilder relink. Without the direct includes, types like Entry/DllImportEntry/MethodDesc are undefined and the build fails. Restore the original includes manually; the generators in src/tasks/WasmAppBuilder/coreclr/ should be updated in a follow-up so they don't strip the includes on regeneration. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 36 out of 36 changed files in this pull request and generated 3 comments.

+        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
+        // The template engine reads installed templates from this location; if it differs
+        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");
+


+                ? inheritedCliHome
+                : Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
            Directory.CreateDirectory(dotnetCliHome);
+            Console.WriteLine($"[diag] DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled: '{dotnetCliHome}' (process inherited: '{inheritedCliHome ?? "<unset>"}')");


+    /// This is needed for tests whose managed program does not use JS interop, because on
+    /// CoreCLR-Wasm the trimmer drops System.Runtime.InteropServices.JavaScript when nothing
+    /// roots it, causing the template main.js to fail at startup with
+    /// Arg_TargetInvocationException out of JSHostImplementation.BindAssemblyExports.


…tive This test relies on a native build pipeline that currently only works on Mono-Wasm. Add [TestCategory("native")] so it is skipped by the NoWorkload CoreCLR-Wasm workitem (which does not run the 'native' category) and is exercised by the mono native workitem instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Move generated wasm relink sources back to including the real CoreCLR headers (<callhelpers.hpp>, <minipal/entrypoints.h>, <minipal/utils.h>) instead of relying on stubs in coreclr_compat.h. This eliminates the drift risk of hand-mirroring StringToWasmSigThunk / ReverseThunkMapEntry / Entry / minipal_resolve_dllimport and lets the in-tree src/coreclr/vm/wasm/callhelpers-*.cpp files share the same source of truth as the WBT-generated pinvoke-table.cpp / wasm_m2n_invoke.g.cpp. Changes: * Revert PInvokeTableGenerator and InterpToNativeGenerator to emit the real #include lines again. * Slim coreclr_compat.h to just the prerequisites callhelpers.hpp assumes are in scope from the in-tree vm/common.h PCH: MethodDesc/PCODE/ULONG typedefs, INTERP_STACK_SLOT_SIZE, and the LF_INTEROP/LL_INFO1000/LOG/PORTABILITY_ASSERT logging stubs. Drop the duplicate g_wasmThunks/g_ReverseThunks/Entry/DllImportEntry decls (now sourced from the real headers). * Ship src/coreclr/vm/wasm/callhelpers.hpp and src/native/minipal/entrypoints.h to the WBT Helix payload alongside the already-shipped minipal/utils.h. * Add CORECLR_VM_WASM_INCLUDE_DIR env var (HelixPreCommand on Helix, RunScriptCommands locally) and wire -I flags in BrowserWasmApp.CoreCLR.targets so the <callhelpers.hpp> / <minipal/...> includes resolve. In-repo fallback paths cover full repo builds. Propagate the env var through the WBT test harness. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 34 out of 34 changed files in this pull request and generated 4 comments.

+        // [diag] Log DOTNET_CLI_HOME inherited by the `dotnet new <template>` invocation.
+        // The template engine reads installed templates from this location; if it differs
+        // from the DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled, the template
+        // won't be found.
+        string inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME") ?? "<unset>";
+        string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
+        Console.WriteLine($"[diag] DOTNET_CLI_HOME inherited by `dotnet new {template.ToString().ToLower()}`: '{inheritedCliHome}' (buildEnv.EnvVars: '{envVarsCliHome}')");
+


+const { setModuleImports, getAssemblyExports, getConfig } = await dotnet
+    .withApplicationArguments("start")
+    .withDiagnosticTracing(true)
+    .withConfig({ forwardConsole: true, appendElementOnExit: true, logExitCode: true, exitOnUnhandledError: true })
+    .create();
+
+const config = getConfig();
+


@@ -67,7 +67,7 @@ await PublishAndRunIcuTest(

    [Theory]
    [MemberData(nameof(FullIcuWithICustomIcuTestData), parameters: new object[] { Configuration.Release })]
-    [TestCategory("native")]
+    [TestCategory("native-coreclr")]


+                ? inheritedCliHome
+                : Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
            Directory.CreateDirectory(dotnetCliHome);
+            Console.WriteLine($"[diag] DOTNET_CLI_HOME used by EnsureWasmTemplatesInstalled: '{dotnetCliHome}' (process inherited: '{inheritedCliHome ?? "<unset>"}')");


Copilot AI review requested due to automatic review settings April 22, 2026 15:30

github-actions Bot added the area-Build-mono label Apr 22, 2026

dotnet-policy-service Bot assigned maraf Apr 22, 2026

Copilot started reviewing on behalf of maraf April 22, 2026 15:33 View session

This comment was marked as resolved.

Sign in to view

maraf added arch-wasm WebAssembly architecture test-enhancement Improvements of test source code os-browser Browser variant of arch-wasm labels Apr 22, 2026

maraf added this to the 11.0.0 milestone Apr 22, 2026

This was referenced Apr 22, 2026

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

[android-arm64] The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#6408

Closed

Copilot AI review requested due to automatic review settings April 24, 2026 08:08

maraf force-pushed the maraf/wbt-coreclr-enable-non-aot-tests branch from 07aa682 to 8debc4a Compare April 24, 2026 08:08

Copilot started reviewing on behalf of maraf April 24, 2026 08:09 View session

This comment was marked as resolved.

Sign in to view

Copilot AI and others added 2 commits April 24, 2026 10:30

Copilot AI review requested due to automatic review settings April 24, 2026 10:03

Copilot started reviewing on behalf of maraf April 24, 2026 10:04 View session

Copilot AI reviewed Apr 24, 2026

View reviewed changes

maraf and others added 2 commits April 24, 2026 12:41

Copilot AI review requested due to automatic review settings April 27, 2026 08:32

Copilot started reviewing on behalf of maraf April 27, 2026 08:33 View session

Copilot AI reviewed Apr 27, 2026

View reviewed changes

maraf and others added 2 commits April 27, 2026 10:26

Copilot AI review requested due to automatic review settings April 27, 2026 11:31

Merge remote-tracking branch 'origin/main' into maraf/wbt-coreclr-ena…

5cc2e7b

…ble-non-aot-tests # Conflicts: # src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs

Copilot AI review requested due to automatic review settings May 14, 2026 07:43

Copilot started reviewing on behalf of maraf May 14, 2026 07:43 View session

Copilot AI reviewed May 14, 2026

View reviewed changes

maraf and others added 3 commits May 14, 2026 13:42

Revert SignatureHelper.cs

f724f75

Revert UCO return type

683b4cd

Copilot AI review requested due to automatic review settings May 14, 2026 14:59

Copilot started reviewing on behalf of maraf May 14, 2026 14:59 View session

Copilot AI reviewed May 14, 2026

View reviewed changes

maraf and others added 2 commits May 14, 2026 18:33

Merge branch 'main' into maraf/wbt-coreclr-enable-non-aot-tests

4140758

Copilot AI review requested due to automatic review settings May 15, 2026 05:05

Copilot started reviewing on behalf of maraf May 15, 2026 05:05 View session

Copilot AI reviewed May 15, 2026

View reviewed changes

radekdoulik added 2 commits May 15, 2026 11:12

Disable EnsureWasmAbiRulesAreFollowedInInterpreter on coreclr

b2d2001

Copilot AI review requested due to automatic review settings May 15, 2026 09:27

Copilot started reviewing on behalf of radekdoulik May 15, 2026 09:27 View session

Copilot AI reviewed May 15, 2026

View reviewed changes

radekdoulik and others added 2 commits May 15, 2026 12:49

Put the structures into WasmAppBuilderTests namespace

f3f030c

Copilot AI review requested due to automatic review settings May 15, 2026 13:08

Copilot started reviewing on behalf of maraf May 15, 2026 13:09 View session

Copilot AI reviewed May 15, 2026

View reviewed changes

maraf and others added 2 commits May 16, 2026 07:39

Copilot AI review requested due to automatic review settings May 16, 2026 13:34

Copilot started reviewing on behalf of maraf May 16, 2026 13:34 View session

Copilot AI reviewed May 16, 2026

View reviewed changes

		[TestCategory("native-coreclr")]
		public class MemoryTests : WasmTemplateTestsBase

Conversation

maraf commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes

Validation

Uh oh!

This comment was marked as resolved.

Uh oh!

dotnet-policy-service Bot commented Apr 22, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

maraf commented Apr 22, 2026 •

edited

Loading