Compiler-Async and Runtime-Async difference for `async Task` methods

[jkoritzinsky]

For a System.Threading.Tasks.Task-returning async method (the Task-returning variant in a runtime-async world), there's a slight difference in the actual type of the return value that has observable semantics.

In compiler-async, the return value's type is Task<VoidTaskResult>. In runtime-async, the return value's type is a non-generic type.

Built-in COM does not support marshalling non-blittable generic types. As a result, after #122195, it is possible to implement a Task-returning method on an interface that is [ComVisible(true)] with an async Task method and have it successfully return a COM object representing the Task. With compiler-async, the marshalling logic throws an exception because Task<VoidTaskResult> is generic and non-blittable.

I don't know if this is something we care about, but I wanted to raise it as an observable compiler-async/runtime-async difference.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[davidwrighton]

In my opinion, this is not a breaking change, and is acceptable, but we should ask ourselves if we want to add a test to keep this behavior the same or if we're ok with this behavior just floating.

Thoughts? @jakobbotsch @VSadov

[AaronRobinsonMSFT]

As a result, after #122195, it is possible to implement a Task-returning method on an interface that is [ComVisible(true)] with an async Task method and have it successfully return a COM object representing the Task.

but we should ask ourselves if we want to add a test to keep this behavior the same or if we're ok with this behavior just floating.

I believe @jkoritzinsky has a test in #122195 for this behavior. It is creating a new feature in built-in COM interop scenarios and that is not something we should be doing. I don't believe we should permit calling this type of API via COM interop and should add a block for it so the behavior matches both compiler-async and runtime-async.

[jkoritzinsky]

My tests in #122195 can be trivially adjusted to validate this behavior (it doesn't validate it at present) by changing the new Task(() => {}); t.Start(); method to be await Task.CompletedTask.

[AaronRobinsonMSFT]

My tests in #122195 can be trivially adjusted to validate this behavior (it doesn't validate it at present) by changing the new Task(() => {}); t.Start(); method to be await Task.CompletedTask.

Okay. My preference is to test it and verify it is blocked. COM interop doesn't need new scenarios.

[jkoritzinsky]

It looks like this occurs because we have a non-generic System.Runtime.CompilerServices.AsyncHelpers.RuntimeAsyncTask type that we use for non-generic tasks. If we remove that type and use System.Runtime.CompilerServices.AsyncHelpers.RuntimeAsyncTask<System.Threading.Tasks.VoidTaskResult> instead, then this scenario will be blocked.

[VSadov]

COM interop doesn't need new scenarios.

+1

I think we can try returning Task<VoidTaskResult> if it is all the same otherwise.

[jakobbotsch]

Yes, it sounds fine to remove RuntimeAsyncTask entirely in favor of RuntimeAsyncTask<VoidTaskResult>. As a bonus it will allow to remove some of the layers of abstraction around RuntimeAsyncTaskCore and RuntimeAsyncTask.Ops vs RuntimeAsyncTask<T>.Ops.