/azp list

/azp run runtime-coreclr outerloop

@jkotas Gave some good feedback offline: we still have some TODOs in the code that will cause breaking changes if this is enabled.

We need to clean those up before we merge. @VSadov do you have an up-to-date list/tracking issue for these?

#115094 is the tracking issue.

There are 26 TODO: (async) comments in the VM right now. Some are just reminders to review the scenario more closely, some are actual issues. We need to get rid of these TODOs one way or another. And since we are close to have Libraries pass with async, it is time to deal with TODOs.

I think a good way to work on this in parallel is logging bugs on each of these (or on areas with TODOs if they are in the same area). Then we can assign the bugs around.

As an example - log issues like: #121754

If the approach sounds reasonable, I will go and make issues for other TODOs.

An example of a tracking issue for something, that I do not think is blocking.
In this case it is the part that we do not yet supporting async methods in PGO.

#121755

I think we should just have tracking issues for these kind of NYIs, not TODOs.

I think we should just have tracking issues for these kind of NYIs,

Yes, tracking issues for perf improvements are fine. I am worried about fixing security issues (the integer overflow example above) and observable behavior changes (the COM interop example above) before we flip the switch.

I think we should just have tracking issues for these kind of NYIs,

Yes, tracking issues for perf improvements are fine. I am worried about fixing security issues (the integer overflow example above) and observable behavior changes (the COM interop example above) before we flip the switch.

Yes, if there is a chance that a TODOs may be hiding a functional regression, I'll keep TODO: (async) in the code.

I will still open issues on individual (or groups of TODOs, when in the same area) - that is just to coordinate when/who is fixing them.

I will still open issues on individual (or groups of TODOs, when in the same area) - that is just to coordinate when/who is fixing them.

This was done.
I have logged 6 issues total and they are referenced from the parent workitem: #115094

The biggest one, IMO, is the COM interop in the presence of runtime async. It may even need to be split further, - I am not familiar with the area enough to tell if COM-to-CLR and CLR-to-COM are here unrelated and can or need to be handled separately.
Not sure if we need to do something with WinRT or it is just a subset.

I think at this point we are just waiting for #122466 to be completed.

There are also 3 TODOs in stub generating helpers about odd-looking pattern and whether it is the best practice - #121754 .
I do not think those are blocking.

I think at this point we are just waiting for #122466 to be completed.

I would be fine with merging this even before #122466 completes. The remaining TODOs do not look critical.

This PR breaks browser/interp probably until we remove the temporary signature detection

To unblock us, we will turn asyncv2 for browser off in #122495
That PR also brings first CI smoke test for CoreCLR/WASM😅

This PR breaks browser/interp probably until we remove the #121064

The temporary signature detection should work just fine with RuntimeAsync=1. I think this suggests that there is a bug exposed by setting RuntimeAsync=1. Wasm just got unlucky to hit this bug first. Opened #122672 on this.