Summary
os_error_to_py_err in rust/cuprum-rust/src/errors.rs has a cfg(windows)
arm that hands the Win32 code to Python via the five-argument OSError
form, so CPython derives errno and the exception subclass from winerror.
Windows wheels are built and shipped, so this arm reaches users.
Nothing executes it. No job runs the Python suite on Windows, so the arm's
runtime behaviour — winerror populated, errno derived, the subclass
selected, and the message formatted without a duplicated code — is unverified.
Current coverage, and its limit
PR #269 adds a windows-cross-check job (cargo check --target x86_64-pc-windows-msvc). That catches a type error or a broken cfg in the
Windows arm on every pull request, which nothing did before: build-wheels.yml
is workflow_call only, so it runs at release rather than on pull requests.
It is a compile check. It cannot show that the five-argument construction
actually produces the fields the users' guide promises.
cuprum/unittests/test_rust_errno.py carries a sys.platform == "win32" skip,
because its assertions name POSIX errno values that do not hold there.
Proposed work
- Add a
windows-2022 job that builds the extension with maturin and runs the
extension-gated modules (make test-extension, or its Windows equivalent).
- Split
test_rust_errno.py so the POSIX expectations stay platform-scoped and
a Windows arm asserts winerror, the derived errno, the exception type,
and the message formatting.
- Update the "Preserving the operating-system error code" section of
docs/developers-guide.md, which currently records that the Windows arm is
verified only by cross-compilation.
Risks
The suite has never run on Windows, so expect unrelated failures — path
handling, os.pipe semantics, and subprocess behaviour — that are not part of
this conversion. Scoping the job to the extension-gated modules first keeps
that tail manageable.
Context
Raised by CodeRabbit on PR #268, where the Windows arm was added in response to
a Codex finding that the two-argument form would assign a Win32 code to errno
and select the wrong subclass. The fix landed; native verification did not.
Summary
os_error_to_py_errinrust/cuprum-rust/src/errors.rshas acfg(windows)arm that hands the Win32 code to Python via the five-argument
OSErrorform, so CPython derives
errnoand the exception subclass fromwinerror.Windows wheels are built and shipped, so this arm reaches users.
Nothing executes it. No job runs the Python suite on Windows, so the arm's
runtime behaviour —
winerrorpopulated,errnoderived, the subclassselected, and the message formatted without a duplicated code — is unverified.
Current coverage, and its limit
PR #269 adds a
windows-cross-checkjob (cargo check --target x86_64-pc-windows-msvc). That catches a type error or a brokencfgin theWindows arm on every pull request, which nothing did before:
build-wheels.ymlis
workflow_callonly, so it runs at release rather than on pull requests.It is a compile check. It cannot show that the five-argument construction
actually produces the fields the users' guide promises.
cuprum/unittests/test_rust_errno.pycarries asys.platform == "win32"skip,because its assertions name POSIX errno values that do not hold there.
Proposed work
windows-2022job that builds the extension with maturin and runs theextension-gated modules (
make test-extension, or its Windows equivalent).test_rust_errno.pyso the POSIX expectations stay platform-scoped anda Windows arm asserts
winerror, the derivederrno, the exception type,and the message formatting.
docs/developers-guide.md, which currently records that the Windows arm isverified only by cross-compilation.
Risks
The suite has never run on Windows, so expect unrelated failures — path
handling,
os.pipesemantics, and subprocess behaviour — that are not part ofthis conversion. Scoping the job to the extension-gated modules first keeps
that tail manageable.
Context
Raised by CodeRabbit on PR #268, where the Windows arm was added in response to
a Codex finding that the two-argument form would assign a Win32 code to
errnoand select the wrong subclass. The fix landed; native verification did not.