aio-libs / multidict / 37144706353

86%

push

github

Bump the version on every resize and share the iteration check (#1658)

<!-- Thank you for your contribution! -->

## What do these changes do?

On the GIL build a resize kept `md->version`; only the free-threaded
build bumped it. An `extend()`, `update()` or `merge()` that grew the
table and then failed (a sequence whose `__len__` is large and whose
iteration raises) therefore swapped `md->keys` without changing the
version. `repr()` reads its entries through a pointer taken before the
loop and rechecks only the version, so a key's or value's `__repr__`
doing that made it read freed memory.

`_md_publish_rebuilt()` now bumps the version on both builds, so a new
table always comes with a new version. The "changed during iteration"
check moved into an always-inline `md_check_version(md, version)` in
`dict.h`, used by `md_next()`, `md_prev()`, `to_dict()`, `repr()` and
both walks in `walk.h`; the walks no longer compare `md->keys`.
`repr()`'s message changed from "MultiDict changed during iteration" to
the "MultiDict is changed during iteration" every other check uses.

The pure Python implementation has no table to resize and is unaffected.

## Are there changes in behavior for the user?

Yes: `repr()` raises `RuntimeError` in that case instead of reading
freed memory, and on the GIL build `getversion()` also changes when a
failed bulk update resized the table.

## Is it a substantial burden for the maintainers to support this?

No.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes (N/A, internal)
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt` (N/A)
- [x] Add a new news fragment into the `CHANGES/` folder
- [x] `make doc-spelling` passes and any new technical words are added
to `docs/spelling_wordlist.txt`

Drafted with Claude Code (Claude Opus 5.5); to be reviewed by @asvetlov.

<details>
<summary>Agent r... (continued)

791 of 1582 branches covered (50.0%)

Branch coverage included in aggregate %.

17 of 17 new or added lines in 1 file covered. (100.0%)

9224 of 10068 relevant lines covered (91.62%)

1.83 hits per line