[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 16 out of 16 changed files in this pull request and generated 4 comments.

[Copilot]

coreclr_compat.h is intended to replace <minipal/utils.h>, but it doesn’t currently define NOINLINE. The generated wasm_m2n_invoke.g.cpp uses NOINLINE for portable-entrypoint thunks, so compilation will fail unless this macro is provided (or the generator includes the proper header again).

[Copilot]

EnvVars is an IDictionary<string, string> (non-null values), but this uses out string? evCliHome and assigns it to a non-null string. With #nullable enable, this is likely to introduce a nullable warning (and may fail the build if warnings are treated as errors). Use out string evCliHome (or null-coalesce) to keep nullability consistent.

Suggested change

	string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string? evCliHome) ? evCliHome : "<unset-in-EnvVars>";
	string envVarsCliHome = s_buildEnv.EnvVars.TryGetValue("DOTNET_CLI_HOME", out string evCliHome) ? evCliHome : "<unset-in-EnvVars>";

[Copilot]

When DOTNET_CLI_HOME is not set in the test process environment, EnsureWasmTemplatesInstalled installs templates into BuildEnvironment.TmpPath via psi.Environment["DOTNET_CLI_HOME"], but the later dotnet new <template> invocation does not set DOTNET_CLI_HOME (and DotNetCommand is created with useDefaultArgs:false, so it won’t apply s_buildEnv.EnvVars). This makes the fallback path inconsistent and can cause templates to not be found on local runs. Consider setting DOTNET_CLI_HOME for the current process and/or passing it explicitly into the dotnet new command as well.

Suggested change

	// 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);
	// writable workitem path); otherwise fall back to TmpPath. Persist the
	// chosen value into the current test process as well so subsequent
	// `dotnet new <template>` invocations (via DotNetCommand with
	// useDefaultArgs:false) inherit the same template cache location.
	string? inheritedCliHome = Environment.GetEnvironmentVariable("DOTNET_CLI_HOME");
	string dotnetCliHome = !string.IsNullOrWhiteSpace(inheritedCliHome)
	? inheritedCliHome
	: Path.Combine(BuildEnvironment.TmpPath, ".dotnet-cli-home");
	Directory.CreateDirectory(dotnetCliHome);
	Environment.SetEnvironmentVariable("DOTNET_CLI_HOME", dotnetCliHome);

[Copilot]

_CoreCLRGenerateManagedToNative still adds Dependencies="$(_WasmCompileRsp);$(_WasmIntermediateOutputPath)coreclr_compat.h" for the generated pinvoke/interp sources later in the file, but this PR removes the intermediate coreclr_compat.h generation and switches to $(MSBuildThisFileDirectory)coreclr_compat.h. Update those remaining Dependencies values to match the new header location (or drop the dependency) to keep incremental builds correct.