summaryrefslogtreecommitdiffstats
path: root/Tools/scripts/generate_global_objects.py
Commit message (Collapse)AuthorAgeFilesLines
* gh-97669: Create Tools/build/ directory (#97963)Victor Stinner2022-10-171-381/+0
| | | | | | | | | | | | | | | | | | | | | | | Create Tools/build/ directory. Move the following scripts from Tools/scripts/ to Tools/build/: * check_extension_modules.py * deepfreeze.py * freeze_modules.py * generate_global_objects.py * generate_levenshtein_examples.py * generate_opcode_h.py * generate_re_casefix.py * generate_sre_constants.py * generate_stdlib_module_names.py * generate_token.py * parse_html5_entities.py * smelly.py * stable_abi.py * umarshal.py * update_file.py * verify_ensurepip_wheels.py Update references to these scripts.
* GH-90699: use statically allocated interned strings in typeobject's slotdefs ↵Kumar Aditya2022-09-071-2/+34
| | | | (GH-94706)
* GH-96458: Statically initialize utf8 representation of static strings (#96481)Kumar Aditya2022-09-031-1/+5
|
* GH-94851: check refcnt of immortal objects after finalization (GH-95001)Kumar Aditya2022-07-251-0/+19
|
* GH-90699: Intern statically allocated strings (GH-93597)Kumar Aditya2022-07-081-4/+10
| | | This is similar to how strings are interned for deepfreeze.
* GH-90699: Move generated static initializer to pycore_runtime_generated.h ↵Kumar Aditya2022-07-071-1/+1
| | | | (GH-94051)
* bpo-46712: share more global strings in deepfreeze (gh-32152)Kumar Aditya2022-04-191-13/+6
| | | (for gh-90868)
* bpo-47146: Avoid Using make Recursively (gh-32206)Eric Snow2022-03-311-1/+6
| | | https://bugs.python.org/issue47146
* bpo-46712: Do not Regen Deep-Frozen Modules before Generating Global Objects ↵Eric Snow2022-03-231-11/+30
| | | | | | | | | (gh-32061) We have to run "make regen-deepfreeze" before running Tools/scripts/generate-global-objects.py; otherwise we will miss any changes to global objects in deep-frozen modules (which aren't committed in the repo). However, building $(PYTHON_FOR_FREEZE) fails if one of its source files had a global object (e.g. via _Py_ID(...)) added or removed, without generate-global-objects.py running first. So "make regen-global-objects" would sometimes fail. We solve this by running generate-global-objects.py before *and* after "make regen-deepfreeze". To speed things up and cut down on noise, we also avoid updating the global objects files if there are no changes to them. https://bugs.python.org/issue46712
* bpo-46881: Statically allocate and initialize the latin1 characters. (GH-31616)Kumar Aditya2022-03-091-0/+13
|
* bpo-46712: Let generate_global_objects.py Run on Earlier Python Versions ↵Eric Snow2022-03-011-1/+1
| | | | | (gh-31637) https://bugs.python.org/issue46712
* bpo-46753: Add the empty tuple to the _PyRuntimeState.global_objects. (gh-31345)Eric Snow2022-02-281-0/+3
| | | https://bugs.python.org/issue46753
* bpo-46712: Share global string identifiers in deepfreeze (GH-31261)Kumar Aditya2022-02-251-5/+9
| | | Where appropriate, deepfreeze.c now uses `&_Py_ID(blah)` references instead of locally defining constants. This saves some space.
* bpo-46541: Scan Fewer Files in generate_global_objects.py (gh-31364)Eric Snow2022-02-161-15/+19
| | | https://bugs.python.org/issue46541
* bpo-46541: Drop the check for orphaned global strings. (gh-31363)Eric Snow2022-02-161-142/+1
| | | https://bugs.python.org/issue46541
* bpo-46541: Discover the global strings. (gh-31346)Eric Snow2022-02-151-255/+74
| | | | | | | Instead of manually enumerating the global strings in generate_global_objects.py, we extrapolate the list from usage of _Py_ID() and _Py_STR() in the source files. This is partly inspired by gh-31261. https://bugs.python.org/issue46541
* Regen the global objects using PYTHON_FOR_REGEN. (gh-31344)Eric Snow2022-02-141-1/+1
| | | https://bugs.python.org/issue46541
* bpo-46541: Replace core use of _Py_IDENTIFIER() with statically initialized ↵Eric Snow2022-02-081-9/+486
| | | | | | | | | | | | | | | | | | | | | | | | | | | | global objects. (gh-30928) We're no longer using _Py_IDENTIFIER() (or _Py_static_string()) in any core CPython code. It is still used in a number of non-builtin stdlib modules. The replacement is: PyUnicodeObject (not pointer) fields under _PyRuntimeState, statically initialized as part of _PyRuntime. A new _Py_GET_GLOBAL_IDENTIFIER() macro facilitates lookup of the fields (along with _Py_GET_GLOBAL_STRING() for non-identifier strings). https://bugs.python.org/issue46541#msg411799 explains the rationale for this change. The core of the change is in: * (new) Include/internal/pycore_global_strings.h - the declarations for the global strings, along with the macros * Include/internal/pycore_runtime_init.h - added the static initializers for the global strings * Include/internal/pycore_global_objects.h - where the struct in pycore_global_strings.h is hooked into _PyRuntimeState * Tools/scripts/generate_global_objects.py - added generation of the global string declarations and static initializers I've also added a --check flag to generate_global_objects.py (along with make check-global-objects) to check for unused global strings. That check is added to the PR CI config. The remainder of this change updates the core code to use _Py_GET_GLOBAL_IDENTIFIER() instead of _Py_IDENTIFIER() and the related _Py*Id functions (likewise for _Py_GET_GLOBAL_STRING() instead of _Py_static_string()). This includes adding a few functions where there wasn't already an alternative to _Py*Id(), replacing the _Py_Identifier * parameter with PyObject *. The following are not changed (yet): * stop using _Py_IDENTIFIER() in the stdlib modules * (maybe) get rid of _Py_IDENTIFIER(), etc. entirely -- this may not be doable as at least one package on PyPI using this (private) API * (maybe) intern the strings during runtime init https://bugs.python.org/issue46541
* bpo-46541: Generate the global objects initializer. (gh-30941)Eric Snow2022-01-271-0/+124
This change is a prerequisite for generating code for other global objects (like strings in gh-30928). (We borrowed some code from Tools/scripts/deepfreeze.py.) https://bugs.python.org/issue46541