Investigate having custom SynchronizationContext that handles async void

[Youssef1313]

Seems reasonable I'd guess. I'd find the behavior more intuitive if it behaved like xunit does: xunit registers its own SynchronizationContext in order to make async void work, both in terms of knowing when the test completes and knowing when an exception occurs. async void still isn't recommended, but having one doesn't put the whole process in jeopardy.

Originally posted by @stephentoub in dotnet/docs#44419 (comment)

@stephentoub Would you expect the custom synchronization context to also "preserve" thread apartment state after an await? Currently, if we have a test method marked as STA, I think the code before the first await will be STA, but the code after may not because it could end up on a ThreadPool thread. Or do you think it's fine to end up non-STA after an await?

cc @Evangelink @MarcoRossignoli As we have had previous discussions around that area.

[Youssef1313]

@stephentoub FYI, xUnit v3 removed their AsyncTestSyncContext and are now disallowing async void test methods completely. An analyzer was implemented with Error severity in xUnit 3 for async void. https://xunit.net/xunit.analyzers/rules/xUnit1049

[Evangelink]

We didn't go toward having any rule as error by default but maybe it does makes sense

[Youssef1313]

@Evangelink The original suggestion is a bit different though.

[stephentoub]

I'm fine if it's simply blocked by default. What I find problematic is the middle ground where it's not blocked but doesn't actually work.

[Youssef1313]

async void test methods are not supported in our case (and in case of xUnit 3 as well). But that "middle ground" still exists if the test method is simply void (not async) and you call some other async void method in it. That part is no longer handled in xUnit 3 (can end up with a silent failure). For our case, we will produce an analyzer warning.