gh-135125: Fix Py_STACKREF_DEBUG build

[efimov-mikhail]

There are two problems with PyStackRef debug builds:

1. Incorrect _PyStackRef_FromPyObjectBorrow function.
   We should provide Py_INCREF here, because each PyStackRef_CLOSE will use Py_DECREF in this mode.
2. No PyStackRef_Wrap and PyStackRef_Unwrap functions.

• Issue: Build fails with Py_STACKREF_DEBUG set. #135125

[efimov-mikhail]

CC @markshannon

[efimov-mikhail]

This PR is just minimal fix for Py_STACKREF_DEBUG build.

I suggest to make changes for this build: provide exactly those flags for indexes as for standard GIL build:

#define Py_INT_TAG 3
#define Py_TAG_INVALID 2
#define Py_TAG_REFCNT 1
#define Py_TAG_BITS 3

And use indexes without flags as real indexes in hash table.
And make all refcounts for DUP, CLOSE and Borrow exactly the same as for standard GIL build.

For example, test.test_list.ListTest.test_list_overwrite_local fails with current variant of PyStackRef debug build because refcounts differ.

[sergey-miryanov]

I'm not sure it is safe to cast void* to uint64 and vice verse. Maybe we should use uintptr_t?

[efimov-mikhail]

We know that Py_STACKREF_DEBUG requires 64 bit machine.
IMO, we could use uint64_t here.
But it's also possible to use uintptr_t bits as in production build, and save indexes in it.

[efimov-mikhail]

This PR is just minimal fix for Py_STACKREF_DEBUG build.

I suggest to make changes for this build: provide exactly those flags for indexes as for standard GIL build:

#define Py_INT_TAG 3
#define Py_TAG_INVALID 2
#define Py_TAG_REFCNT 1
#define Py_TAG_BITS 3

And use indexes without flags as real indexes in hash table. And make all refcounts for DUP, CLOSE and Borrow exactly the same as for standard GIL build.

For example, test.test_list.ListTest.test_list_overwrite_local fails with current variant of PyStackRef debug build because refcounts differ.

I provide those changes.
IMO, this variant is better than minimal fix:

1. Two tests test_list and test_capi don't fail with this but fail with minimal fix.
2. We have exactly the same refcount scheme and it's easier to understand what's going on.
3. Future changes for StackRef build will be more obvious.

[efimov-mikhail]

CC @mpage

[mpage]

This looks good to me. In the future I'd recommend splitting this into two PRs (and associated issues): one that is the minimal fix for the build and another that unifies the refcounting behavior. I'd like to give Mark a chance to review this as I'm not sure if he wants to preserve the refcounting behavior in the debug build. I've added him as a reviewer.

[efimov-mikhail]

This looks good to me. In the future I'd recommend splitting this into two PRs (and associated issues): one that is the minimal fix for the build and another that unifies the refcounting behavior. I'd like to give Mark a chance to review this as I'm not sure if he wants to preserve the refcounting behavior in the debug build. I've added him as a reviewer.

Thanks! I thought about two separate PRs but I wasn't sure about that.
I can make another PR with minimal fix if needed.