[wasm][coreclr] Enable more libraries tests

[radekdoulik]

No description provided.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Enables a broader set of library test suites to run under WASM CoreCLR by removing many browser/CoreCLR test exclusions and extending timeouts to accommodate longer execution.

Changes:

• Reduced the browser/CoreCLR test exclusion list to allow more test projects to execute.
• Increased Helix work item timeout for TargetOS=browser + RuntimeFlavor=CoreCLR.
• Increased the XHarness per-suite timeout for WASM tests when RuntimeFlavor=CoreCLR.

Reviewed changes

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

File	Description
src/libraries/tests.proj	Removes many browser/CoreCLR exclusions, reclassifies remaining exclusions (failures vs long-running).
src/libraries/sendtohelixhelp.proj	Raises Helix _workItemTimeout for browser/CoreCLR to 2 hours.
eng/testing/tests.wasm.targets	Raises WasmXHarnessTestsTimeout for CoreCLR to 2 hours.

[Copilot]

WasmXHarnessTestsTimeout is now extended to 2 hours for all Wasm test projects when RuntimeFlavor=CoreCLR (this file is imported by both tests.browser.targets and tests.wasi.targets). However, the Helix work item timeout was only extended for TargetOS=browser in sendtohelixhelp.proj. If CoreCLR/WASI runs exist (or are added later), XHarness could wait up to 2 hours while Helix still cancels at 30 minutes. Consider either scoping this timeout to TargetOS=browser here, or adding a matching CoreCLR/WASI _workItemTimeout override in sendtohelixhelp.proj so the two layers stay consistent.

Suggested change

	<WasmXHarnessTestsTimeout Condition="'$(WasmXHarnessTestsTimeout)' == '' and '$(RuntimeFlavor)' == 'CoreCLR'">02:00:00</WasmXHarnessTestsTimeout>
	<WasmXHarnessTestsTimeout Condition="'$(WasmXHarnessTestsTimeout)' == '' and '$(RuntimeFlavor)' == 'CoreCLR' and '$(TargetOS)' == 'browser'">02:00:00</WasmXHarnessTestsTimeout>

[Copilot]

Within the browser/CoreCLR exclusions block, the top-level comment says these exclusions are due to build errors and test failures, but this change introduces a new subsection for long-running suites ("these run for too long"), which is a different reason. To keep the documentation accurate for future maintainers, update the block’s header comment to include timeouts/long-running tests (or otherwise clarify the criteria for exclusions in this block).

Suggested change

	<!-- these run for too long -->
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Linq\tests\System.Linq.Tests.csproj" />
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Memory\tests\System.Memory.Tests.csproj" />
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Private.Xml\tests\System.Private.Xml.Tests.csproj" />
	<!-- timeout (>30 min) -->
	<!-- Long-running suites that currently exceed browser/CoreCLR time budgets (for example, timeouts > 30 minutes),
	in addition to the build and test failures excluded elsewhere in this block. -->
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Linq\tests\System.Linq.Tests.csproj" />
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Memory\tests\System.Memory.Tests.csproj" />
	<ProjectExclusions Include="$(MSBuildThisFileDirectory)System.Private.Xml\tests\System.Private.Xml.Tests.csproj" />