GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||
GeezerVison is showing github.com — gh-142913: Add test case for interpreter generator w/ overridden opcodes by DinoV · Pull Request #142911 · python/cpython Conversation
|
| #define Py_BUILD_CORE_MODULE | ||
| #endif | ||
|
|
||
| #include "../../Python/ceval.h" |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Third-party interpreter loops will still need to borrow the contents of Python/ceval.h and Python/ceval_macros.h, right? At some point it'd be nice if we could avoid borrowing these as well.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I think depends on what you mean by "borrow". They'll need to include them (which should require a little extra work as the files aren't in Include). For ceval.h we could potentially do better but that's in-avoidable for ceval_macros.h as they are in fact (mostly) macros.
But this does put them in a place where rather than needing to do any actual copying they can build and re-use those source files. A re-generated interpreter could have some minor drift between patch versions of Python but because the bytecodes.c + ceval.h are all cohesive they should just either be missing or have extra bug fixes vs the patch version they're running on.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
If I'm an extension author how would I set up my build so that I can include these files? I was assuming that since they aren't in Include I would probably need to copy them into my own source tree...
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
This broke the JIT builds/tests it seems with |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
This partially reverts commit 4d5a676 (pythonGH-142911) This test fails when re-run in --huntrleaks mode.
Summary: Fixes up the CinderX build after the latest import. This brought in python/cpython#142911 which move somethings into ceval.h so that we can directly include it rather than borrowing those functions. We bring back `cinderx-only-headers` and now use them on 3.10 and 3.15+. There's also a fix related to python/cpython#143569 where we need to update the interpreter loop. Also python/cpython@bb25f72 seems to have refactored `_PyDict_LookupIndex` to use `_PyDict_LookupIndexAndValue`. There's some more work after this to further reduce our usage of `ceval_macros.h` but this just gets things working again. Reviewed By: itamaro Differential Revision: D91146024 fbshipit-source-id: 6da3ef18fe5fe5f79e29a71cdbe98491bbb45a9d
…n opcodes (python#142911) Add test case for interpreter generator w/ overridden opcodes
…4110) This partially reverts commit 4d5a676 (pythonGH-142911) The removed test fails when re-run in --huntrleaks mode.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
Add test coverage for interpreter loop generator overridden insts
There was an error while loading. Please reload this page.