fix(stl_bind): correct __delitem__ for negative-step slices and re-enable contiguous erase fast path

[henryiii]

🤖 AI text below 🤖

Bug

bind_vector's __delitem__(slice) in stl_bind.h advanced the erase
index by step - 1 for every slice, but that correction is only valid
for positive steps (where erasing an element shifts the later
elements down by one). For negative steps the visited indices are
strictly decreasing, so erasing never shifts them and the - 1 is
wrong:

• del v[::-2] on [0, 1, 2, 3] produced [1, 2] instead of the
  correct [0, 2] (silent data corruption).
• del v[::-1] ended up calling v.erase(v.begin() - 1), an
  out-of-bounds access (observed SIGBUS).

Separately, the contiguous fast path was guarded by step == 1 && false
— a debugging artifact from 2016 (25c03ce) — so a contiguous delete
like del v[1:1000] did 999 individual erase calls instead of one
range erase.

Fix

• Use the signed slice::compute overload so negative steps stay signed
  instead of arriving as wrapped size_t values.
• Original: Advance by step for negative steps and step - 1 for positive
  steps. — Revised: fix(stl_bind): correct __delitem__ for negative-step slices and re-enable contiguous erase fast path #6088 (comment)
• Drop the dead && false, restoring the O(n) contiguous range erase for
  step == 1.

Semantics now match CPython del l[slice] exactly for forward,
strided, negative, empty, and full slices.

Tests

Added test_vector_delitem_slice in tests/test_stl_binders.py,
looping over forward / strided / negative-step / empty / full slices for
vectors of several lengths and comparing against the equivalent Python
list del.

Verification

Built a scratch opaque VectorInt module against this branch's headers
and compared del v[...] to Python list semantics across all the slice
cases above (and more) for lengths 0–11 — all match, no out-of-bounds
access.

Part of #6084

---

📚 Documentation preview 📚: https://pybind11--6088.org.readthedocs.build/

[rwgk]

Background on the additional commits

I pushed three follow-up commits after another close review of the slice-deletion changes.

Codex originally found a signed-overflow edge case in the forward-erasure loop. The loop updated start after every erase, including the final one. For example, slice(3, None, sys.maxsize) selects only one element, but after erasing it the old code still evaluated start += step - 1. With step == SSIZE_MAX, that unused final calculation could overflow signed ssize_t, which is undefined behavior.

Looking at that finding manually led to a more fundamental question: for a positive stride, why erase the selected elements from the front? If a slice selects indices 1, 3, 5, 7, erasing them as 7, 5, 3, 1 means that no erase shifts an index that remains to be processed. Negative-step slices already arrive in descending order, so the implementation can put both cases on the same path by starting a positive-step slice at its last selected index and negating the step.

This is simpler than compensating for forward erasure with step - 1, and for std::vector it is also more efficient because elements that are themselves scheduled for deletion are not repeatedly shifted. It also resolves the original overflow concern structurally: the large positive step is converted to a negative descending step, and the loop performs no index update after the final erase.

The additional commits are:

• 94df278 — add coverage for a sys.maxsize positive step, a negative step with negative bounds, and the zero-step error path (including verifying that the vector remains unchanged);
• 105011e — erase non-contiguous slices in descending index order, while retaining the contiguous step == 1 range-erase fast path; and
• 1c64b2c — simplify the loop by using slicelength directly as the number of erasures remaining, eliminating the separate loop variable and the i + 1/++i bookkeeping.

pre-commit and the full test suite pass locally; the newly triggered CI is running now.