-
Notifications
You must be signed in to change notification settings - Fork 747
geninterop.py doesn't handle c_ast.FuncDecl; creates broken interop38.cs #995
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If I get https://docs.python.org/3/c-api/typeobj.html#c.PyVectorcall_Call correctly, |
[EDITED]I think
were added after Since |
The repo's current You can see it crash in the REPL
|
If you manually fix
|
pycparser doesn't support https://github.com/eliben/pycparser/wiki/FAQ#does-pycparser-support-gnuvisual-c-extensions so I'm guessing that But ignoring my Windows issues, there's a problem in the automated workflow producing |
I got the I added this case to
and implemented it as
And now I get the correct mapping struct, with a So this is a bug in For those curious, this is how
|
Fixed in 627cac0. |
Details
I'm concerned that the automated process pythonnet uses to generate the interop[version].cs file might be flawed. This is the relevant snippet from
object.h
this is how I mapped those fields in my handmade interop38.cs
but here's how the auto-generated interop38.cs maps them
Notice the missing public static int tp_print = 0;
I'm thinking that the
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
messed up the auto-gen technique? Won't all fields followingtp_vectorcall
be offset incorrectly due to this?The text was updated successfully, but these errors were encountered: