Fix GetModule_ReturnsModule test failure on browser-wasm

[lewing]

The else branch added in PR #125080 assumed !HasAssemblyFiles implies NativeAOT, but browser-wasm also has !HasAssemblyFiles (since Assembly.Location is empty). On wasm (Mono), Module.Name returns the real DLL name ("System.Reflection.Context.Tests.dll"), not "<Unknown>", so the assertion fails.

Split the else branch to handle NativeAOT and wasm separately:

• NativeAOT: assert Module.Name == "<Unknown>"
• wasm/other: call GetModule(moduleName) and assert not null

Fixes #125245

[Copilot]

Pull request overview

Fixes a failing System.Reflection.Context test on browser-wasm by separating the previous !HasAssemblyFiles behavior into distinct expectations for NativeAOT vs wasm/other platforms, aligning assertions with runtime-specific Module.Name results.

Changes:

• Update GetModule_ReturnsModule to treat !HasAssemblyFiles as either NativeAOT (expect "<Unknown>") or non-NativeAOT (expect GetModule(name) succeeds).
• Keep the test unconditionally runnable while branching assertions per platform behavior.

[lewing]

@danmoseley we need tests that work for all the versions of the platforms including the outerloops can you take a look please.

[agocke]

Longer term we should have a plan for converging behavior, I.e. coreclr has a consistent behavior for these situations and I presume we will continue to use that behavior on wasm.

[danmoseley]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

Are these two outerloops everything? If they are green too we can merge this?

And in terms of learnings for me, it's that before merging reflection-related test changes I should run various outerloops.

For the match pattern in #125051, I'm not sure what it should have been to be more specific.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

You can also share your feedback on Copilot code review. Take the survey.

[MichalStrehovsky]

This was still failing in extra-platforms, so I just put it into the same shape as it was before the https://github.com/dotnet/runtime/pull/125080/changes/BASE..335d280da92111f93afaf584e71f75759831c494#r2880967707 comment.

That comment was not particularly helpful but it was part of a batch of 17 copilot comments and it was easier to just let copilot add harmless/useless extra coverage than to tell it to only apply 15 out of the 17 comments.

This ended up being not harmless.

(The Module.Name returning <Unknown> is not a native AOT specific behavior, we defined this for all form factors where assemblies no longer exist on disk. Native AOT actually has this name but we're purposefully dropping it to align with PublishSingleFile.)

[MichalStrehovsky]

/azp run runtime-extra-platforms, runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

And in terms of learnings for me, it's that before merging reflection-related test changes I should run various outerloops.

Use your best judgement on what's likely affected.

There are 5 - 10 regressions sneaking in every week in what's not tested by the CI by default. Every area with optional runs is affected - diagnostics, codegen, hw intrinsics, nativeaot, mobile, wasm, ... . I do not think we can realistically prevent this by testing more in the CI by default. I think we need to work on a better process how to deal with the regressions that sneaked in so that people do not feel frustrated.

For the match pattern in #125051, I'm not sure what it should have been to be more specific.

The match pattern in #125051 is just a test name. The test can fail for any number of reasons and it would still match. The test can succeed and some unrelated test in the same workitem fails, it can still match - some configurations output names of passing tests in the log too and build analysis is a simple pattern match on the log. A better more specific match pattern would be: ["[FAIL] System.Reflection.Context.Tests.ExtendedAssemblyTests2.GetModule_ReturnsModule","Assert.NotNull() Failure: Value is null"],

[danmoseley]

["[FAIL] System.Reflection.Context.Tests.ExtendedAssemblyTests2.GetModule_ReturnsModule","Assert.NotNull() Failure: Value is null"],

That was why I didn't know how to make it better - I didn't know this allowed an array. This doesn't seem to be documented:

https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#regex-matching

[jkotas]

This doesn't seem to be documented:
https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#regex-matching

The document mentions it in https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#fill-out-known-issues-with-a-list-of-errors . I agree that the document does not have a good flow.

[jkotas]

/ba-g Filled #125295 on the new regression, the remaining failures are non-actionable timeouts and deadletters