Print UTC timestamps at the beginning and end of the test run to make
it immediately clear when tests started and whether they ran to
completion. The DONE message includes the Catch session result value.
Example output:
[ STARTING ] 2025-12-21 03:23:20.497Z
[ PYTHON ] 3.14.2 ...
[ RUN ] Threads
[ OK ] Threads
[ DONE ] 2025-12-21 03:23:20.512Z (result 0)
This test verifies that gil_safe_call_once_and_store provides separate
storage for each interpreter when subinterpreter support is enabled.
The test caches the interpreter ID in the main interpreter, then creates
a subinterpreter and verifies it gets its own cached value (not the main
interpreter's). Without per-interpreter storage, the subinterpreter would
incorrectly see the main interpreter's cached object.
This test hangs in Py_EndInterpreter() when the subinterpreter is
destroyed from a different thread than it was created on.
The hang was observed:
- Intermittently on macOS with Python 3.14.0t
- Predictably on macOS, Ubuntu, and Windows with Python 3.14.1t and 3.14.2t
Root cause analysis points to an interaction between pybind11's
subinterpreter creation code and CPython's free-threaded runtime,
specifically around PyThreadState_Swap() after PyThreadState_DeleteCurrent().
See detailed analysis: https://github.com/pybind/pybind11/pull/5933
Add a custom Catch2 streaming reporter that prints one line per test
case as it starts and ends, with immediate flushing to keep CI logs
current. This makes it easy to see where the embedded/interpreter
tests are spending time and to pinpoint which test case is stuck
when builds hang (e.g., free-threading issues).
The reporter:
- Prints "[ RUN ]" when each test starts
- Prints "[ OK ]" or "[ FAILED ]" when each test ends
- Prints the Python version once at the start via Py_GetVersion()
- Uses StreamingReporterBase for immediate output (not buffered)
- Is set as the default reporter via CATCH_CONFIG_DEFAULT_REPORTER
This approach gives visibility into all tests without changing their
behavior, turning otherwise opaque 90-minute CI timeouts into
locatable issues in the Catch output.
Add a 3-minute timeout to all C++ test (cpptest) steps across all
platforms to detect hangs early. This uses GitHub Actions' built-in
timeout-minutes property which works on Linux, macOS, and Windows.
Use std::unique_ptr to hold the newly allocated storage map until
the capsule is successfully created. This prevents a memory leak
if capsule creation throws an exception.
Clarify why the finalize callback parameter is intentionally ignored
when subinterpreter support is disabled: the storage is process-global
and leaked to avoid destructor calls after interpreter finalization.
The `using atomic_bool = ...` declaration was at global scope,
polluting the global namespace. Move it into pybind11::detail
to avoid potential conflicts with user code.
* Limit busy-wait loops in per-subinterpreter GIL test
Add explicit timeouts to the busy-wait coordination loops in the
Per-Subinterpreter GIL test in tests/test_with_catch/test_subinterpreter.cpp.
Previously those loops spun indefinitely waiting for shared atomics like
`started` and `sync` to change, which is fine when CPython's free-threading
and per-interpreter GIL behavior matches the test's expectations but becomes
pathologically bad when that behavior regresses: the `test_with_catch`
executable can then hang forever, causing our 3.14t CI jobs to time out
after 90 minutes.
This change keeps the structure and intent of the test but adds a
std::chrono::steady_clock deadline to each of the coordination loops,
using a conservative 10 second bound. Worker threads record a failure and
return if they hit the timeout, while the main thread fails the test via
Catch2 instead of hanging. That way, if future CPython free-threading
patches change the semantics again, the test will fail quickly and
produced a diagnosable error instead of wedging the CI job.
* Revert "Limit busy-wait loops in per-subinterpreter GIL test"
This reverts commit 7847adacda.
* Add progress reporter for test_with_catch Catch runner
Introduce a custom Catch2 reporter for tests/test_with_catch that prints a
simple one-line status for each test case as it starts and ends, and wire the
cpptest CMake target to invoke test_with_catch with -r progress. This makes
it much easier to see where the embedded/interpreter test binary is spending
its time in CI logs, and in particular to pinpoint which test case is stuck
when the free-threading builds hang.
Compared to adding ad hoc timeouts around potentially infinite busy-wait
loops in individual tests, a progress reporter is a more general and robust
approach: it gives visibility into all tests (including future ones) without
changing their behavior, and turns otherwise opaque 90-minute timeouts into
locatable issues in the Catch output.
* Temporarily limit CI to Python 3.14t free-threading jobs
* Temporarily remove non-CI GitHub workflow files
* Temporarily disable AppVeyor builds via skip_commits
* Add DEBUG_LOOK in TEST_CASE("Move Subinterpreter")
* Add Python version banner to Catch progress reporter
Print the CPython version once at the start of the Catch-based
interpreter tests using Py_GetVersion(). This makes it trivial to
confirm which free-threaded build a failing run is using when
inspecting CI or local logs.
* Revert "Add DEBUG_LOOK in TEST_CASE("Move Subinterpreter")"
This reverts commit ad3e1c34ce.
* Pin CI free-threaded runs to CPython 3.14.0t
Update the standard-small and standard-large GitHub Actions jobs to
request python-version 3.14.0t instead of 3.14t. This forces setup-python
to use the last-known-good 3.14.0 free-threaded build rather than the
newer 3.14.1+ builds where subinterpreter finalization regressed.
* Revert "Pin CI free-threaded runs to CPython 3.14.0t"
This reverts commit 5281e1c20c.
* Revert "Temporarily disable AppVeyor builds via skip_commits"
This reverts commit ed11292636.
* Revert "Temporarily remove non-CI GitHub workflow files"
This reverts commit 0fe6a42a04.
* Revert "Temporarily limit CI to Python 3.14t free-threading jobs"
This reverts commit 60ae0e8f74.
* Pin CI free-threaded runs to CPython 3.14.0t
Update the standard-small and standard-large GitHub Actions jobs to
request python-version 3.14.0t instead of 3.14t. This forces setup-python
to use the last-known-good 3.14.0 free-threaded build rather than the
newer 3.14.1+ builds where subinterpreter finalization regressed.
* Switch NVHPC job to ubuntu-24.04 and disable AppVeyor
* Temporarily trim workflows to focus on NVHPC job
* First restore ci.yml from test-with-catch-timeouts branch, then delete all jobs except ubuntu-nvhpc7
* Change runner to ubuntu-24.04
* Use nvhpc-25-11
* Undo ALL changes relative to master (i.e. this branch is now an exact copy of master)
* Change runner to ubuntu-24.04
* Use nvhpc-25-11
* Remove misleading 7 from job name (i.e. ubuntu-nvhpc7 → ubuntu-nvhpc)
* Fix PyObject_HasAttrString return value
Signed-off-by: cyy <cyyever@outlook.com>
* Tidy unchecked files
Signed-off-by: cyy <cyyever@outlook.com>
* [skip ci] Handle PyObject_HasAttrString error when probing __notes__
PyObject_HasAttrString may return -1 to signal an error and set a
Python exception. The previous logic only checked for "!= 0", which
meant that the error path was treated the same as "attribute exists",
causing two problems: misreporting the presence of __notes__ and
leaving a spurious exception pending.
The earlier PR tightened the condition to "== 1" so that only a
successful lookup marks the error string as [WITH __notes__], but it
still left the -1 case unhandled. In the context of
error_fetch_and_normalize, we are already dealing with an active
exception and only want to best-effort detect whether normalization
attached any __notes__. If the attribute probe itself fails, we do not
want that secondary failure to affect later C-API calls or the error
we ultimately report.
This change stores the PyObject_HasAttrString return value, treats
"== 1" as "has __notes__", and explicitly calls PyErr_Clear() when
it returns -1. That way, we avoid leaking a secondary error while
still preserving the original exception information and hinting
[WITH __notes__] only when we can determine it reliably.
* Run clang-tidy with -DPYBIND11_HAS_SUBINTERPRETER_SUPPORT
* [skip ci] Revert "Run clang-tidy with -DPYBIND11_HAS_SUBINTERPRETER_SUPPORT"
This reverts commit bb6e751de4.
---------
Signed-off-by: cyy <cyyever@outlook.com>
Co-authored-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
* adding windows arm test
- excluding numpy 2.2.0 for arm64 builds
* adding windows arm msys2 test
* testing mingw python
* unnamed namespace test on windows arm with clang and mingw
* Revert "unnamed namespace test on windows arm with clang and mingw"
This reverts commit 08abf889ae.
* bumping c++ version
* commenting out other tests
* Ignore unnmaed namespace on arm windows with mingw
- Updatig XFAIL condition to expect a failure on windows arm with
mingw and clang
- setting python home and path variables in c++ tests
* Revert "commenting out other tests"
This reverts commit dc75243963.
* removing windows-11-arm from big test, push
* removing redundant shell
* removing trailing whitespace
* Clarify Windows ARM clang job naming
Rename the Windows ARM clang jobs to windows_arm_clang_msvc and windows_arm_clang_msys2 and adjust their display names to clang-msvc / clang-msys2. The first runs clang against the MSVC/Windows SDK toolchain and python.org CPython for Windows ARM, while the second runs clang inside the MSYS2/MinGW-w64 CLANGARM64 environment with MSYS2 Python.
Using clearly distinguished job names makes it easier to discuss failures and behavior in each environment without ambiguity, both in logs and in PR review discussions.
* Reduce Windows ARM clang matrix size
Limit the windows_arm_clang_msvc job to Python 3.13 and the windows_arm_clang_msys2 job to Python 3.12 to stay within our constrained GitHub Actions resources. Keep both jobs using a matrix over os and python so their structure stays aligned and it remains easy to expand coverage when needed.
* Remove matrix.python from windows_arm_clang_msys2 job: the Python version is determined by the msys2/setup-msys2 action and cannot be changed
---------
Co-authored-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
* Apply ruff/flake8-implicit-str-concat rule ISC003
ISC003 Explicitly concatenated string should be implicitly concatenated
* Enforce ruff/flake8-implicit-str-concat rules (ISC)
* Apply ruff/Perflint rule PERF102
PERF102 When using only the values of a dict use the `values()` method
* Apply ruff/Perflint rule PERF401
PERF401 Use a list comprehension to create a transformed list
* Enforce ruff/Perflint rules (PERF)
* [skip ci] Point main README.rst to CI for supported platforms and compilers
- **Replace** the hard-coded “Supported compilers” and “Supported platforms” lists in `README.rst`.
- **Point** readers to the current GitHub Actions matrix as the source of truth for tested platforms, compilers, and Python/C++ versions.
- **Clarify** that the matrix evolves over time and that configurations users care about can be kept working via contributions.
- **Avoid stale documentation**: Enumerating specific compiler and platform versions in the README is both burdensome and error-prone, and tends to drift out of sync with reality.
- **Align “supported” with “tested”**: In practice, the CI configuration is the only place where we can say with confidence which combinations are exercised. Nearby versions (e.g., adjacent compiler minor releases) will often work, but we cannot test every variant.
- **Reflect actual maintenance capacity**: pybind11 is maintained by a small, volunteer-based community, so support is necessarily best-effort. Pointing to CI and inviting contributions better matches how support is provided in practice.
- **No behavior change**: This PR updates documentation only.
- **Living source of truth**: As CI jobs are added or removed, the linked Actions view will automatically reflect the set of configurations we actively test. Keeping a configuration in CI is the best way to keep it “supported”.
* [skip ci] Slight rewording: point out GitHub's limits on concurrent jobs under the free tier (rather than free minutes).
* Remove enum from bold in doc
* [skip ci] Remove bold formatting around (see #5528)
---------
Co-authored-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
* Don't allow keep_alive or call_guard on properties
The def_property family blindly ignore the keep_alive and call_guard arguments passed to them making them confusing to use.
This adds a static_assert if either is passed to make it clear it doesn't work.
I would prefer this to be a compiler warning but I can't find a way to do that. Is that even possible?
* style: pre-commit fixes
* Re-run tests
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Type hint make_tuple / fix *args/**kwargs return type
Signed-off-by: Michael Carlstrom <rmc@carlstrom.com>
* add back commented out panic
* ignore return std move clang
Signed-off-by: Michael Carlstrom <rmc@carlstrom.com>
* fix for mingmw
Signed-off-by: Michael Carlstrom <rmc@carlstrom.com>
* added missing case
Signed-off-by: Michael Carlstrom <rmc@carlstrom.com>
---------
Signed-off-by: Michael Carlstrom <rmc@carlstrom.com>
