Looks like I may not have got the gdb lib changes exactly right, I can take another look at those on a Linux system once I've had some input on whether this direction is feasible, i.e. I know it's worth me spending the time to debug.

I don't find the Rust argument convincing -- we should expose good API functions, rather than make internal structs easy to use. Or is there a performance-sensitive use case? (If there is we might want to add some higher-level API for it, rather than making you play with bits.)

I do think this should change. Exposing compiler-implementation-defined behavior in the API is a ticking bomb.

IMO, if it changes it should change to bit masks. With this PR, there's no way to add an additional unrelated flag. (And one might be needed soon for static/immortal objects).

Both a version with bit masks and the PR as is are an API change. Per PEP 387, it needs a deprecation warning period or a SC exception.
(If you take the current PR and wrap the fields instructstate, it might not be an API change -- but as above, fouru8s are painting ourselves in a corner.)
IMO, since this isn't time-sensitive, we should deprecate thestate struct (for use outside CPython), and after a deprecation period, make it an 32-bit int and use it with use bit masks. And make the bit masks themselves private, or at leastunstable, so that users preferably go through the public accessor functions.

Meanwhile, for Rust, you can expose the accessors as actual API functions, while keeping thestatic inline versions. There's a bit of a dance to do that, see e.g. (1,2,3) forPyVectorcall_NARGS.

Thanks@encukou, I wasn't aware that this struct would need the deprecation cycle applied.

I'll replace this PR with one proposing API functions. To check I understand, as per thePyVectorcall_NARGS dance, I'll need to add these accessors to the stable API?

I'll need to add these accessors to the stable API?

No, unlike vectorcall, they don't need to be in thelimited API/stable ABI. (They can be added later if needed.)
The dance is to avoid having onlyinline functions (which can be faster but are only usable from C/C++).

Superseded by#115211 (which may itself yet be superseded by something else, who knows!)