[browser] More Wasm.Build.Tests on CoreCLR

[maraf]

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]

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

[Copilot]

Pull request overview

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

[Copilot]

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]

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]

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]

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]

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.

[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();

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

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

• EnsureWasmTemplatesInstalled may install templates into a fallback DOTNET_CLI_HOME under BuildEnvironment.TmpPath when the process doesn't already have DOTNET_CLI_HOME set, but the subsequent dotnet new <template> call uses DotNetCommand(useDefaultArgs:false) and does not set DOTNET_CLI_HOME. In that case dotnet new will look in the default CLI home and won't see the installed templates. Consider explicitly setting DOTNET_CLI_HOME on the dotnet new invocation (or setting it for the current process) to guarantee both steps share the same template cache in local runs.

        EnsureWasmTemplatesInstalled();

        // [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();

[Copilot]

New header file is missing the standard .NET Foundation MIT license header comment used throughout the repo. Please add the usual "Licensed to the .NET Foundation under one or more agreements..." block at the top for consistency/compliance.

[Copilot]

The new comment says the template main.js would cause the JS interop assembly to be linked away by the trimmer, but the reason to replace main.js seems to be the opposite: avoid calling JS interop APIs (setModuleImports/getAssemblyExports) so the app doesn't depend on JS interop being preserved. Please clarify the comment to reflect the actual failure mode/intent (e.g., default main.js calls these APIs but the app doesn't reference the managed JS interop pieces, so trimming can remove them and the default main.js would then fail at runtime).

Suggested change

	// The template main.js calls JS interop APIs (setModuleImports, getAssemblyExports)
	// which the ICU test program does not use. Replace it with a minimal version tailored
	// for ICU tests, otherwise the JS interop assembly would be linked away by the trimmer.
	// The template main.js calls JS interop APIs (setModuleImports, getAssemblyExports),
	// but the ICU test program does not reference the managed JS interop pieces. Trimming
	// can therefore remove them, and the default main.js would then fail at runtime, so
	// replace it with a minimal version tailored for ICU tests that avoids those APIs.

[Copilot]

With the class category changed to "native-coreclr", this test class will now run on the CoreCLR WBT lane (which sets SDK_HAS_WORKLOAD_INSTALLED=false). In that lane, AllocateLargeHeapThenRepeatedlyInterop calls BuildProject(... ExpectSuccess: BuildTestBase.IsUsingWorkloads) which becomes false, so the test effectively expects the build to fail and then doesn't run/validate anything. If the intent is to start exercising this scenario on CoreCLR, consider splitting the workload/no-workload variants (or tagging the workload-only [Fact] with TestCategory("workload")) and making the CoreCLR-enabled path assert a successful native rebuild instead of treating failure as success.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 30 out of 30 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:245

• EnsureWasmTemplatesInstalled picks a fallback DOTNET_CLI_HOME when the process doesn’t already have one, but the subsequent dotnet new <template> invocation uses DotNetCommand(useDefaultArgs:false) and therefore inherits DOTNET_CLI_HOME from the test process. If it’s unset, templates may be installed into the fallback directory but dotnet new will still look in the default CLI home and fail to find the template. Consider setting DOTNET_CLI_HOME for the current process (or explicitly for the dotnet new command) when you choose the fallback path, so install and usage always share the same template cache.

            // Use the inherited DOTNET_CLI_HOME if set (Helix workitems set this to a
            // writable workitem path); otherwise fall back to TmpPath. Aligning with
            // the inherited value ensures `dotnet new install` and the subsequent
            // `dotnet new <template>` invocation share the same template cache —
            // those `dotnet new <template>` calls (via DotNetCommand with
            // useDefaultArgs:false) inherit DOTNET_CLI_HOME from the test process.
            string? inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME");
            string dotnetCliHome = !string.IsNullOrWhiteSpace(inheritedCliHome)
                ? 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>"}')");

            // Use the same isolated environment as the rest of the test suite
            // (DOTNET_ROOT/DOTNET_INSTALL_DIR/PATH/NUGET_PACKAGES overrides), so
            // `dotnet new install` picks up the harness's SDK and NuGet config.
            foreach (var kvp in s_buildEnv.EnvVars)
                psi.Environment[kvp.Key] = kvp.Value;
            psi.Environment["DOTNET_SKIP_FIRST_TIME_EXPERIENCE"] = "1";
            psi.Environment["DOTNET_CLI_HOME"] = dotnetCliHome;

[maraf]

Note

Generated by Copilot CLI.

While triaging WBT-NoWorkload-CLR-ST-Wasm.Build.Tests.PInvokeTableGeneratorTests, two failure classes remain that are not addressed by the recent commits and need a closer look from @pavelsavara / @radekdoulik:

A. PInvokeTableGenerator blittability error not emitted under CoreCLR-Wasm

These tests assert that the build fails with error.*Parameter.*types.*pinvoke.*blittable from Mono's PInvokeTableGenerator. CoreCLR's PInvokeTableGenerator does not emit that error, so the build succeeds and BuildProjectWithoutAssert trips the ExpectSuccess: false assertion (same situation as NativeLibraryWithVariadicFunctions, which is already [TestCategory("mono")]):

• UnmanagedStructAndMethodIn_SameAssembly_WithoutDisableRuntimeMarshallingAttribute_NotConsideredBlittable (Release)
• UnmanagedStructsAreConsideredBlittableFromDifferentAssembly — expectSuccess: False variants:
  • Debug, libraryHasAttribute:False, appHasAttribute:False
  • Debug, libraryHasAttribute:True, appHasAttribute:False
  • Release, libraryHasAttribute:False, appHasAttribute:False
  • Release, libraryHasAttribute:True, appHasAttribute:False

Likely fix: gate the negative variants as [TestCategory("mono")], or have CoreCLR's PInvokeTableGenerator emit an equivalent diagnostic.

B. CoreCLR runtime assert: portableEntryPoint->HasNativeCode()

• UnmanagedCallersOnly_Namespaced (Release, aot:False)

Browser exits with [error] CLR: Assert failure(PID 42 [0x0000002a], Thread: 1 [0x1]): portableEntryPoint->HasNativeCode() before user Main can run. This looks like a real CoreCLR-Wasm bug around [UnmanagedCallersOnly] resolution in the interpreter / portable-entrypoint path, not a test-harness issue.

[Copilot]

Pull request overview

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