[BUG] Bug with limited API support in trivial program involving float literal about cython

[da-woods]

The upshot is that we can't use PyFloat_Type because it's opaque. The C compiler knows that it exists but doesn't know what's in it.

__Pyx_PyFloat_EqObjC (and related functions) are largely just optimisations. As a fallback they could just be replaced with the standard PyObject comparison in the limited API.

I suspect in case we could use __Pyx_PyType_GetSlot on PyFloat_Type. This should end up equivalent to the current code normally, and something slightly less efficient but valid in the limited API.

[vyasr]

I figured out the opaque struct bit, what I was having trouble understanding is what code gen cython is doing to produce the invalid code. The error is coming up right after the limited api macros are defined and python.h is included, so almost none of the cython generated code has been hit. How is what cython doing triggering this error from just the include of python.h?

[da-woods]

The error is the line

PyFloat_Type.tp_richcompare(op2, op1, Py_EQ));

All the other messages are just telling you that PyFloat_Type is an incomplete type and is defined in "Python.h". They're informational.

[vyasr]

Ah right I didn't look at the C traceback nearly closely enough, sorry about that. Any idea why the issue is so obscured in the C++ traceback? I do see the

/home/coder/.conda/envs/rapids/include/python3.11/floatobject.h: In function 'PyObject* __Pyx_PyFloat_EqObjC(PyObject*, PyObject*, double, int, int)':

which is the function you mentioned as being an optimization, but I don't see the equivalent obvious error line indicating where the incomplete type is being used. Apologies if this is obvious to see, I suspect that I'm having trouble tracing because I'm not accustomed to using macros nearly to the extent used in the Cython/CPython code bases and they make tracebacks harder to follow.

[da-woods]

I'm going off the C traceback instead. I think they're expressing the same issue in slightly different ways. I can't actually see the relevant line in the C++ traceback you've posted.