diff options
author | Guido van Rossum <guido@python.org> | 2024-03-18 18:11:10 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-03-18 18:11:10 (GMT) |
commit | 7e1f38f2de8f93de362433203faa5605a0c47f0e (patch) | |
tree | af7b0edad82614c2e8f646934fad5286e1211723 /Objects | |
parent | 76d086890790f1bfbe05d12e02cadb539db5b0b1 (diff) | |
download | cpython-7e1f38f2de8f93de362433203faa5605a0c47f0e.zip cpython-7e1f38f2de8f93de362433203faa5605a0c47f0e.tar.gz cpython-7e1f38f2de8f93de362433203faa5605a0c47f0e.tar.bz2 |
gh-116916: Remove separate next_func_version counter (#116918)
Somehow we ended up with two separate counter variables tracking "the next function version".
Most likely this was a historical accident where an old branch was updated incorrectly.
This PR merges the two counters into a single one: `interp->func_state.next_version`.
Diffstat (limited to 'Objects')
-rw-r--r-- | Objects/codeobject.c | 6 | ||||
-rw-r--r-- | Objects/funcobject.c | 8 |
2 files changed, 7 insertions, 7 deletions
diff --git a/Objects/codeobject.c b/Objects/codeobject.c index 30336fa..3df733e 100644 --- a/Objects/codeobject.c +++ b/Objects/codeobject.c @@ -415,9 +415,9 @@ init_code(PyCodeObject *co, struct _PyCodeConstructor *con) co->co_ncellvars = ncellvars; co->co_nfreevars = nfreevars; PyInterpreterState *interp = _PyInterpreterState_GET(); - co->co_version = interp->next_func_version; - if (interp->next_func_version != 0) { - interp->next_func_version++; + co->co_version = interp->func_state.next_version; + if (interp->func_state.next_version != 0) { + interp->func_state.next_version++; } co->_co_monitoring = NULL; co->_co_instrumentation_version = 0; diff --git a/Objects/funcobject.c b/Objects/funcobject.c index 08b2823..a506166 100644 --- a/Objects/funcobject.c +++ b/Objects/funcobject.c @@ -236,8 +236,9 @@ How does a function's `func_version` field get initialized? - A new version is allocated by `_PyFunction_GetVersionForCurrentState` when the specializer needs a version and the version is 0. -The latter allocates versions using a counter in the interpreter state; -when the counter wraps around to 0, no more versions are allocated. +The latter allocates versions using a counter in the interpreter state, +`interp->func_state.next_version`. +When the counter wraps around to 0, no more versions are allocated. There is one other special case: functions with a non-standard `vectorcall` field are not given a version. @@ -247,8 +248,7 @@ Code object versions -------------------- So where to code objects get their `co_version`? -There is a per-interpreter counter, `next_func_version`. -This is initialized to 1 when the interpreter is created. +They share the same counter, `interp->func_state.next_version`. Code objects get a new `co_version` allocated from this counter upon creation. Since code objects are nominally immutable, `co_version` can |