Skip to content

style: name _ext's array types so clang-format output is stable - #409

Merged
lgray merged 2 commits into
scikit-hep:mainfrom
graphed-org:clang-format-aliases
Oct 8, 2026
Merged

lgray merged 2 commits into
scikit-hep:mainfrom
graphed-org:clang-format-aliases

Conversation

@lgray

@lgray lgray commented Oct 7, 2026

Copy link
Copy Markdown
Collaborator

🤖 AI text below 🤖

Follows @henryiii's suggestion on #408. src/_ext.cpp already goes through the pinned clang-format hook, but its formatting depends on a parse quirk: clang-format does not treat the binding lambdas as lambdas while their parameter types are py::array_t<double, py::array::c_style | py::array::forcecast> (the | inside the template arguments). Any change to those parameter types, such as a move to the limited API, then re-indents the whole module body; in #408 that was a 2k-line style-only commit.

This PR names the two array types once (array_d, array_i), so clang-format parses the lambdas, and takes the one-time re-indent now:

  • refactor: name the array parameter types of _ext — the aliases; no other change.
  • style: clang-format src/_ext.cpp — the pinned hook's output (clang-format 23.1.2). Apart from whitespace, it only wraps three long comments.

After this, changing what array_d/array_i stand for touches those two lines and nothing else under clang-format.

Checks: with the aliases undone and whitespace and comment markers ignored, the reformatted file is identical to main. It builds, and the full test suite passes locally (148 tests; macOS arm64, Python 3.12).

@lgray
lgray merged commit 46100f9 into scikit-hep:main Oct 8, 2026
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant