[BCSharp]

This PR uses the DLR's async-body tracing (IronLanguages/dlr#369): the tracing variant of an async function hands its Async/AsyncEnumerable node the function's debug context, so the body is traced while the coroutine runs. Creating the coroutine is no longer traced, as in CPython.

Also, some smaller fixes:

• The body's entry point is at the start of the function again, and an async def now starts at its async keyword, so the 'call' location (and ast col_offset) match CPython.
• Setting f_lineno on an async body frame raises ValueError (jumping is not supported there yet).
• Fixes IronPython's GeneratorRewriter, like the DLR's in 369: an exception handler containing a yield that left its loop iteration early (continue/break) ran again after a later pass through the try that raised nothing. This affected sync generators, and async functions on .NET Framework as well.

The DLR submodule is updated to the one with the async-body tracing implementation.
Fixes #2065, though for the full debugging support, f_locals and jumps in an async body frame are still needed.

[slozier]

The CI failure is probably unrelated:

import sys
def f():
    class Boom(Exception): pass

sys.settrace(lambda *a: None)
f() 
sys.settrace(None)
f() # TypeError: Unable to cast ... Func`2[PythonFunction,Object] ... Func`2[CodeContext,CodeContext]

[BCSharp]

I cannot reproduce any test failure (on Windows , using .NET 8). Also your sample code runs fine on my Windows system. In the log I also noticed something suspicious: test_asyncgen was skipped for an unknown reason. It should run under .NET 8, and normally does.

I'll try to rerun the CI check.

[slozier]

Also your sample code runs fine on my Windows system

Interesting, for me this fails the majority of the time everywhere I tried (windows, mac, linux).

test_asyncgen was skipped for an unknown reason

it's marked as ignore...

[IronPython.test_asyncgen]
Ignore=true
RunCondition='$(FRAMEWORK)' <> '.NETFramework,Version=v4.6.2'
Reason=Requires IAsyncEnumerable & IAsyncDisposable

[BCSharp]

Interesting, for me this fails the majority of the time everywhere I tried (windows, mac, linux).

I was finally able to reproduce it. It happens occasionally on my systems, which suggests a race condition of some sort. I was able to trigger it on both net8.0 and net10.0. But more interestingly, it can happen also on main, so the bug predates this PR. I will look into it in a separate PR.

it's marked as ignore...

That's wrong — it is supposed to be ignored only on .NET Framework/Mono. I will patch the .ini file here.

[slozier]

Thanks, looks good to me!