[TEST] Enable runtime async tests

[VSadov]

Just to run async tests.
I want to figure the set of changes that would make the PR green.

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[VSadov]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[VSadov]

browser-wasm seems to be trying to run runtime async tests and fails.

[VSadov]

src/tests/issues.targets excludes async for wasm, so I am confused why it still tries to run.

[VSadov]

Or could it be that the Await intrinsic is mixed up with something else and called directly as an entry point or something?

[16:58:57] info: === TEST EXECUTION SUMMARY ===
[16:58:57] info: Tests run: 25 Passed: 0 Inconclusive: 0 Failed: 0 Ignored: 0 Skipped: 25
[16:58:57] info: 
[16:58:57] info: System.NotImplementedException: The method or operation is not implemented.
[16:58:57] info:    at System.Runtime.CompilerServices.AsyncHelpers.Await[Int32](Task`1 task)
[16:58:57] info:    at Program.<Main>$(String[] args)
[16:58:57] info: MONO_WASM: Specified cast is not valid.
[16:58:57] info:    at System.Runtime.InteropServices.JavaScript.JSHostImplementation.CallEntrypoint(IntPtr assemblyNamePtr, String[] args, Boolean waitForDebugger)
[16:58:57] info: Error: Specified cast is not valid.
[16:58:57] info:     at un (/root/helix/work/workitem/e/_framework/dotnet.runtime.js:3:27531)
[16:58:57] info:     at cn (/root/helix/work/workitem/e/_framework/dotnet.runtime.js:3:26767)
[16:58:57] info:     at an (/root/helix/work/workitem/e/_framework/dotnet.runtime.js:3:26621)
[16:58:57] info:     at /root/helix/work/workitem/e/_framework/dotnet.runtime.js:3:178673
[16:58:57] info:     at Object.Vc [as runMain] (/root/helix/work/workitem/e/_framework/dotnet.runtime.js:3:178755)
[16:58:57] info:     at async run (/root/helix/work/workitem/e/test-main.js:361:32)
[16:58:57] info:     at async /root/helix/work/workitem/e/test-main.js:377:1
[16:58:57] info: Process v8 exited with 1
                 
[16:58:57] info: Waiting to flush log messages with a timeout of 120 secs ..
[16:58:57] fail: Application has finished with exit code 1 but 0 was expected
XHarness exit code: 71 (GENERAL_FAILURE)
/root/helix/work/workitem/e /root/helix/work/workitem/e

[VSadov]

@lewing @pavelsavara - who could help with figuring what is going on with wasm + async ?

[lewing]

@lewing @pavelsavara - who could help with figuring what is going on with wasm + async ?

What IL does the compiler generate for an async main here? For wasm we can't call the regular compiler generated entrypoint because we need to access the Task directly so I'm guessing the logic we use to detect the wrapper and then look up Main is failing now.

[VSadov]

What IL does the compiler generate for an async main here?

The way this should work is that there is an experimental C# compiler that is used to compile tests under $(XunitTestBinBase)/async/**. Everything else uses the regular toolset compiler.

The new IL for async/await would make sense only for a runtime that understands runtime async. I.E. - C# await may be emitted as a call to AsyncHelpers.Await intrinsic that JIT will need to expand to actually await something as appropriate.

We only have support for that in ordinary JIT-based coreclr (and even that is disabled in regular builds), thus I am trying to exclude async/** tests for everything else until more platforms understand runtime async.

[VSadov]

Generally, async methods are emitted for runtime async as-in-source, since the actual state machine is done by the JIT. A few corner cases as await in exception handlers require some changes. I do not think the C# compiler that we use can do that yet, so we can assume "as in the source".

Runtime async methods have the same signature in IL as well - i.e, if the signature has Task as return type in source then IL signature has Task as return type as well.

Runtime async methods are marked with MethodImpl.Async

Ideally nothing under $(XunitTestBinBase)/async/** would be compiled for wasm at all, so all the above would not matter.

[VSadov]

I did not realize that excluding tests in src/tests/issues.targets may still make them to build and run.

I think I can try adding <DisableProjectBuild Condition="'$(TargetArchitecture)' == 'wasm'">true</DisableProjectBuild> in Directory.Build.targets.

Let me try that.
If that works I'd probably use that to exclude mono and NativeAOT as well.

[VSadov]

Looks like it worked. wasm leg passed. Thanks @lewing

[VSadov]

The only failure now is the artificial PR-fail due to NOMERGE label.

Otherwise, the PR that enables both the runtime async feature and tests for it (and all preexisting tests too) is green - on all platforms that we currently support.

[VSadov]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).