Generators have a "gi_running" attribute (coroutines have an equivalent cr_running flag). Internally frame also has an executing flag.

We use these, plus the test `f_stacktop pointer == NULL`, to determine what state a generator or frame is in.

It would be much cleaner to maintain a single f_state field in the frame to track the state of a frame, reducing the change of ambiguity and error.

The possible states of a frame are:
CREATED -- Frame exists but has not been executed at all
SUSPENDED -- Frame has been executed, and has been suspended by a yield
EXECUTING -- Frame is being executed
RETURNED -- Frame has completed by a RETURN_VALUE instruction
RAISED -- Frame has completed as a result of an exception being raised
CLEARED -- Frame has been cleared, either by explicit call to clear or by the GC.

This change combines the explicit state in `PyFrameObject.f_excuting` and `PyGenObject.gi_running`, and the implicit state in `PyFrameObject.f_stacktop == NULL` and `PyFrameObject.f_last == -1` into a single enum field in `PyFrameObject`.

Since we no longer need to test `PyFrameObject.f_stacktop == NULL` , The `f_stacktop` pointer can be replaced with a `f_stackdepth` integer, which make for simpler code when iterating over the stack and avoids the potential hazard of NULL pointers.

There are  three benefits to these changes:

1. The code is more robust and, IMO, easier to understand, as all state is now explicit.
2. It carries additional information about the state of the frame. Information about whether a frame exiting by `return` or by `raise` is available.
3. A modest reduction in size of frame and generator objects.

Mark, I want to flag issue29590 for you ("Incorrect stack traces when re-entering a generator/coroutine stack via .throw()") in case this issue relates to or would help at all with that.

issue29590 is unrelated

New changeset cb9879b948a19c9434316f8ab6aba9c4601a8173 by Mark Shannon in branch 'master':
bpo-40941: Unify implicit and explicit state in the frame and generator objects into a single value. (GH-20803)
https://github.com/python/cpython/commit/cb9879b948a19c9434316f8ab6aba9c4601a8173

The change introduced compiler warnings on Windows:

c:\vstinner\python\master\python\ceval.c(1448): warning C4244: '=': conversion  
from '__int64' to 'int', possible loss of data [C:\vstinner\python\master\PCbui 
ld\pythoncore.vcxproj]
c:\vstinner\python\master\python\ceval.c(2254): warning C4244: '=': conversion  
from '__int64' to 'int', possible loss of data [C:\vstinner\python\master\PCbui 
ld\pythoncore.vcxproj]
c:\vstinner\python\master\python\ceval.c(2271): warning C4244: '=': conversion  
from '__int64' to 'int', possible loss of data [C:\vstinner\python\master\PCbui 
ld\pythoncore.vcxproj]

New changeset 71f2ff4ccf4ff8bdb56cc30d115ca2ddc602b12f by Victor Stinner in branch 'master':
bpo-40941: Fix fold_tuple_on_constants() compiler warnings (GH-22378)
https://github.com/python/cpython/commit/71f2ff4ccf4ff8bdb56cc30d115ca2ddc602b12f

New changeset b7d8d8dbfe83040087a63662e0b908f4b5ac24b0 by Victor Stinner in branch 'master':
bpo-40941: Fix stackdepth compiler warnings (GH-22377)
https://github.com/python/cpython/commit/b7d8d8dbfe83040087a63662e0b908f4b5ac24b0

The main change is merged, and I fixed compiler warnings. It seems like there is no remaining thing to do, so I close the issue.

Thanks Victor.
Sorry I didn't get round to this sooner

No problem. These warnings are only visible on 64-bit Windows. I spotted them waiting looking at some Windows errors.