gh-145497: Use same size of static_types array in all builds#149139
gh-145497: Use same size of static_types array in all builds#149139encukou wants to merge 4 commits intopython:mainfrom
Conversation
When someone adds a new type but doesn't increment `_Py_MAX_MANAGED_STATIC_BUILTIN_TYPES` or `_Py_MAX_MANAGED_STATIC_EXT_TYPES`, JIT tests fail, because JIT builds define an extra type. But the JIT tests don't necessarily run for the commit that causes the failure. As a workaround, use the same size for the array for all builds, potentially with an empty spot.
Documentation build overview
53 files changed ·
|
|
Why not :) |
ZeroIntensity
left a comment
ZeroIntensity
left a comment
There was a problem hiding this comment.
LGTM as well.
To be clear: If we forget to update _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES from now on, it won't be possible to merge the PR, right? (If not, that's fine -- I think we should do this regardless.)
Correct. If you add an entry to |
| @@ -531,7 +531,9 @@ struct _py_func_state { | |||
|
|
|||
| /* For now we hard-code this to a value for which we are confident | |||
| all the static builtin types will fit (for all builds). */ | |||
There was a problem hiding this comment.
The 83 still needs to be bumped if you add some categories of new types, right?
Would be useful to rewrite the comment to something like "If you add a new type, you may have to update some of these numbers".
4 participants
When someone adds a new type but doesn't increment
_Py_MAX_MANAGED_STATIC_BUILTIN_TYPESor_Py_MAX_MANAGED_STATIC_EXT_TYPES, JIT tests fail, because JIT builds define an extra type.But the JIT tests don't necessarily run for the commit that causes the failure,
so the issue only shows up in subsequent PR(s) that touch the JIT.
As a workaround, use the same size for the array for all builds, potentially with an empty spot.