fix: ak.from_iter of np.clongdouble, 0-d arrays, and np.void scalars

[lgray]

🤖 AI text below 🤖

Bug

ak.from_iter segfaults on np.clongdouble:

>>> import numpy as np, awkward as ak
>>> ak.from_iter([np.clongdouble(1 + 1j)])
Segmentation fault

builder_fromiter (awkward-cpp/src/python/content.cpp) has no branch for complex numpy scalars other than complex128 (a Python complex subclass), so np.clongdouble reaches the tolist branch. np.clongdouble.tolist() returns the scalar itself, and the builder recurses until the stack overflows. The same happens for a clongdouble ndarray, and for ak.from_iter(ak.to_list(<clongdouble array>)).

The same function also recurses without a bound on anything that never bottoms out: a tolist()/to_list() that returns another such object, a 0-d object array that contains itself, or very deep nesting with a raised sys.setrecursionlimit. Each of these segfaults on main.

Fix

In builder_fromiter:

• np.complexfloating scalars are built as complex128, the same widening complex64 already gets.
• A 0-d np.ndarray recurses on obj[()]. Before, tolist() dropped the datetime64/timedelta64 unit (datetime64[ns] gave int64) and the field names of a structured value.
• A structured np.void scalar becomes a record over dtype.names; an unstructured one becomes bytes. Before, a structured scalar was iterated as a list (var * float64, ints turned into floats).
• The recursion depth is capped at min(sys.getrecursionlimit(), 1000) and exceeding it raises RecursionError.

In ErrorContext.format_argument, arguments are formatted with a reprlib.Repr bounded in depth. With a raised recursion limit on CPython 3.10 and 3.11, the plain repr() of the deep argument overflowed the stack while the RecursionError message was being built. The text is unchanged for any argument that fits in the message.

Behavior changes

• A 1-d structured ndarray or recarray now gives a record. ak.from_iter([np.array([(1, 2.5)], dtype=[("a", "i8"), ("b", "f8")])]) gave 1 * var * var * float64 and now gives 1 * var * {a: int64, b: float64}; the same for .view(np.recarray). This is what ak.from_numpy gives for the same array.
• Nesting deeper than about 1000 levels raises RecursionError whatever sys.getrecursionlimit() is. At the default limit, main already raises RecursionError from Python-level code for a list nested 987 to 20,000 deep inside [x], but segfaults at 200,000 deep (macOS arm64, and in the linux/amd64 test run below); this branch raises RecursionError at every one of those depths. With a raised limit, main built deeper nesting until the stack overflowed; this branch raises from 999 levels. The cap is not tied to sys.getrecursionlimit() because a raised limit brings the segfault back, and neither CPython's C recursion limit (Py_EnterRecursiveCall) nor the limit stays below the stack's capacity for these frames. Nesting that deep could not be used anyway: ak.forms.from_json of the resulting form raises RecursionError at depth 1000.

Tests

tests/test_4392_from_iter_numpy_scalars.py: values checked against ak.from_numpy, clongdouble scalars/0-d/ndarrays, the non-terminating members and the depth cap. The cases that crash on main run in a subprocess (skipped on emscripten, as in test_2682), so on main they fail rather than take down the test session.

On main, 19 of the first 29 tests fail and 10 pass, on macOS arm64 and on linux/amd64 with awkward-cpp built from the tree. The later commits add a dict member to the non-terminating cases, test_argument_text_matches_repr (including a dict nested past the depth cap, which found that reprlib.Repr.fillvalue does not exist on 3.10) and test_argument_whose_repr_raises. On this branch all 38 tests pass on macOS arm64 with CPython 3.13 and 3.10; with the format_argument change reverted, the two raised-limit members fail on 3.10.

Found by the numpy-dtype survey behind #4390.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.10%. Comparing base (1f04d6f) to head (55f2271).

Additional details and impacted files

Files with missing lines	Coverage Δ
src/awkward/_errors.py	85.82% <100.00%> (+1.24%)	⬆️

[lgray]

py3.14t failing for unrelated reasons (build itself fails, PR does not touch CI config)