[mypyc] Add experimental C extension librt.vecs (part 2/2)#20656
Merged
[mypyc] Add experimental C extension librt.vecs (part 2/2)#20656
Conversation
p-sawicki
reviewed
Jan 28, 2026
mypyc/lib-rt/vecs/vec_nested.c
Outdated
Comment on lines
397
to
403
| if (self->item_type && !Vec_IsMagicItemType(self->item_type)) { | ||
| Py_DECREF(VEC_BUF_ITEM_TYPE(self)); | ||
| self->item_type = 0; | ||
| } | ||
| for (Py_ssize_t i = 0; i < VEC_BUF_SIZE(self); i++) { | ||
| Py_CLEAR(self->items[i].buf); | ||
| } |
Collaborator
There was a problem hiding this comment.
Suggested change
| if (self->item_type && !Vec_IsMagicItemType(self->item_type)) { | |
| Py_DECREF(VEC_BUF_ITEM_TYPE(self)); | |
| self->item_type = 0; | |
| } | |
| for (Py_ssize_t i = 0; i < VEC_BUF_SIZE(self); i++) { | |
| Py_CLEAR(self->items[i].buf); | |
| } | |
| VecNestedBuf_clear(self); |
mypyc/lib-rt/vecs/vec_t.c
Outdated
| } | ||
| VecTObject *obj = PyObject_GC_New(VecTObject, &VecTType); | ||
| if (obj == NULL) { | ||
| // vec.buf is always defined, so no need for a NULL heck |
Collaborator
There was a problem hiding this comment.
Suggested change
| // vec.buf is always defined, so no need for a NULL heck | |
| // vec.buf is always defined, so no need for a NULL check |
mypyc/lib-rt/vecs/vec_t.c
Outdated
Comment on lines
392
to
398
| if (self->item_type) { | ||
| Py_DECREF(VEC_BUF_ITEM_TYPE(self)); | ||
| self->item_type = 0; | ||
| } | ||
| for (Py_ssize_t i = 0; i < VEC_BUF_SIZE(self); i++) { | ||
| Py_CLEAR(self->items[i]); | ||
| } |
Collaborator
There was a problem hiding this comment.
Suggested change
| if (self->item_type) { | |
| Py_DECREF(VEC_BUF_ITEM_TYPE(self)); | |
| self->item_type = 0; | |
| } | |
| for (Py_ssize_t i = 0; i < VEC_BUF_SIZE(self); i++) { | |
| Py_CLEAR(self->items[i]); | |
| } | |
| VecTBuf_clear(self); |
Comment on lines
+294
to
+296
| // Keep a duplicate item, since there could be another reference | ||
| // to the buffer with a longer length, and they expect a valid reference. | ||
| Py_XINCREF(items[v.len - 1]); |
Collaborator
There was a problem hiding this comment.
won't this cause leaks if another item is appended afterward?
p-sawicki
reviewed
Jan 28, 2026
Comment on lines
+262
to
+265
| memset(new.buf->items + vec.len, 0, sizeof(PyObject *) * (new_size - vec.len)); | ||
| // Clear the items in the old vec. We avoid reference count manipulation. | ||
| memset(vec.buf->items, 0, sizeof(PyObject *) * vec.len); | ||
| new.buf->items[vec.len] = x; |
Collaborator
There was a problem hiding this comment.
do we need to handle the ref count of the objects in items[len, cap) that were increfed in remove?
nevermind this won't happen, we'll always have len < cap after remove so we only this handling in the other branch.
p-sawicki
approved these changes
Jan 28, 2026
JukkaL
added a commit
that referenced
this pull request
Feb 3, 2026
Add basic irbuild support for `vec[t]`. The runtime representation of `vec[t]` is a C struct. This is similar to how fixed-length tuples are represented. Multiple different structs are used, depending on the item type (`VecI32` for `vec[i32`] and so on). The C extension `librt.vec` that defines the `vec` type was added in #20653 and #20656. These PRs also explain the implementation in more detail. Add RType subclass RVec that is used for vecs. We need a new RType class, since primitives types can't be generic and they can't be struct types. This is based on an old branch, so it mostly uses old-style primitives. I am planning to modernize some of the primitives in follow-up PRs. This doesn't include codegen support, and irbuild test cases are only included for `vec[i64]`. I will create follow-up PRs that add the remaining irbuild tests, codegen support and run tests. All these tests are are passing on my local full branch. Related issue: mypyc/mypyc#840
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support for
vectypes with reference item types, such asvec[str]orvec[MyClass | None]. Arbitrary union item types aren't supported -- only optional types are accepted. Also add support for nested vecs, such asvec[vec[i64]].No mypyc primitives are included in this PR yet. I'll add them in follow-up PRs.
This continues the work started in #20653. Refer to that PR for a more detailed description of the feature.
Related issue: mypyc/mypyc#840