Example (minimal version ofhttps://github.com/python-trio/trio/issues/425):-----async def open_file():    passasync def main():    async with open_file():  # Should be 'async with await open_file()'        passcoro = main()coro.send(None)-----Here we accidentally left out an 'await' on the call to 'open_file', so the 'async with' tries to look up 'CoroutineType.__aexit__', which obviously doesn't exist, and the program crashes with an AttributeError("__aexit__"). Yet weirdly, this doesn't trigger a warning about 'open_file' being unawaited. It should!Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.

> Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.Nope, that doesn't seem to be it. This version prints "refcount: 2" twice, *and* prints a proper "was never awaited" warning:-----import sysasync def open_file():    passasync def main():    open_file_coro = open_file()    print("refcount:", sys.getrefcount(open_file_coro))    try:        async with open_file_coro:            pass    except:        pass    print("refcount:", sys.getrefcount(open_file_coro))coro = main()try:    coro.send(None)except:    pass

Looking at the ceval code, I think Yury's theory is plausible, and we may also be leaving the interpreter's internal stack in a dubious state. Things then get cleaned up if you wrap the async with in a try/except or try/finally:==============>>> async def try_main():...     try:...         async with open_file():...             pass...     finally:...         pass... >>> try_main().send(None)sys:1: RuntimeWarning: coroutine 'open_file' was never awaitedTraceback (most recent call last):  File "<stdin>", line 1, in <module>  File "<stdin>", line 3, in try_mainAttributeError: __aexit__==============Unfortunately for that theory, adding braces and "Py_DECREF(POP());" to the relevant error handling branch *doesn't* fix the problem.I also found another way to provoke similar misbehaviour without async with:==========>>> async def open_file():...     pass... >>> open_file()<coroutine object open_file at 0x7f92fe19c548>>>> _<coroutine object open_file at 0x7f92fe19c548>>>> 1__main__:1: RuntimeWarning: coroutine 'open_file' was never awaited1>>> open_file()<coroutine object open_file at 0x7f92fe19c548>>>> del _Traceback (most recent call last):  File "<stdin>", line 1, in <module>NameError: name '_' is not defined>>> _<coroutine object open_file at 0x7f92fe19c548>>>> 11>>> _1>>> ==========

Changing  async def main():    async with open_file():      passto  async def main():    c = open_file()    async with c:      passalso makes it print the warning :)Also I've made a test out of this snippet and running tests in refleak mode shows that there's indeed no refleak here.

The difference between these two functions is two extra opcodes: STORE_FAST/LOAD_FAST before BEFORE_ASYNC_WITH.  With them we have a warning.

So refactoring it into "c = open_file(); async with c" just prolongs the life of the coroutine so that it's GCed outside of WITH_CLEANUP_START/WITH_CLEANUP_FINISH block.  Something weird is going on in that block.

Ah, we should never really get to WITH_CLEANUP_START; the exception should be raised in BEFORE_ASYNC_WITH

So the problem was that _PyGen_Finalize wasn't issuing any warnings if there's any error set in the current tstate.  And in Nathaniel's case, the current error was an AttributeError('__aexit__').This check is weird, because right before raising the warning, we call PyErr_Fetch to temporarily reset the current exception if any, specifically to raise the warning :)The PR just removes the check.  Unless I'm missing something this should fix the issue.

Well, I feel silly then:bpo-32605

Ah, and in my REPL example, the NameError was pending when the internal result storage was getting set back to None.I'm not sure I even knew the "Don't complain when an exception is pending" check existed, so it would have taken me a long time to find that.

I knew about that "if", but it never fully registered to me why it's there and what it is protecting us from ;) So I had to debug half of ceval loop before I stumbled upon it again ;)

New changeset2a2270db9be9bdac5ffd2d50929bf905e7391a06 by Yury Selivanov in branch 'master':bpo-32703: Fix coroutine resource warning in case where there's an error (GH-5410)https://github.com/python/cpython/commit/2a2270db9be9bdac5ffd2d50929bf905e7391a06

Merged; closing this issue.