mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-08-04 08:59:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

gh-116916: Remove separate next_func_version counter (#116918)

Browse source 
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`.
This commit is contained in:
Guido van Rossum 2024-03-18 11:11:10 -07:00 • committed by GitHub
parent 76d0868907
commit 7e1f38f2de
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 7 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

8
Objects/funcobject.c
View file

@ -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