Walkthrough

This change introduces a new PythonFinalizationError exception type to the VM's exception system and uses it to prevent preexec_fn execution during interpreter shutdown in the POSIX subprocess module. The exception type is registered as a builtin exception subclassing PyRuntimeError, with a corresponding factory method added to VirtualMachine.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• impl preexec_fn #6479: Related changes to preexec_fn handling in fork_exec() and VM threading through execution context
• Convert new_X_error to use a macro #5814: Introduces the define_exception_fn! macro pattern for generating exception constructor methods on VirtualMachine

Poem

🐰 A finalization guard hops into view,
Preexec_fn shutdown—now blocked on cue,
New exception type, cleanly designed,
Error handling flow, precisely aligned! 🎯

Pre-merge checks and finishing touches

• 📝 Generate docstrings

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Reviewing files that changed from the base of the PR and between 5e1fc93 and 406376c.

• Lib/multiprocessing/connection.py is excluded by !Lib/**
• Lib/multiprocessing/resource_tracker.py is excluded by !Lib/**
• Lib/multiprocessing/util.py is excluded by !Lib/**

• crates/stdlib/src/posixsubprocess.rs
• crates/vm/src/exceptions.rs
• crates/vm/src/vm/vm_new.rs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.rs: Follow the default rustfmt code style by running cargo fmt to format Rust code
Always run clippy to lint code (cargo clippy) before completing tasks and fix any warnings or lints introduced by changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass, pymodule, pyfunction, etc.) when implementing Python functionality in Rust

Files:

• crates/stdlib/src/posixsubprocess.rs
• crates/vm/src/vm/vm_new.rs
• crates/vm/src/exceptions.rs

Learnt from: youknowone
Repo: RustPython/RustPython PR: 6358
File: crates/vm/src/exception_group.rs:173-185
Timestamp: 2025-12-09T08:46:58.660Z
Learning: In crates/vm/src/exception_group.rs, the derive() method intentionally always creates a BaseExceptionGroup instance rather than preserving the original exception class type. This is a deliberate design decision that differs from CPython's behavior.

Applied to files:

• crates/vm/src/vm/vm_new.rs
• crates/vm/src/exceptions.rs

• GitHub Check: Run snippets and cpython tests (windows-latest)

crates/stdlib/src/posixsubprocess.rs (1)

36-46: LGTM! Guard correctly prevents preexec_fn execution during shutdown.

The early check with Ordering::Acquire is appropriate for reading a flag potentially set by another thread, and the placement before resource allocation avoids unnecessary work when the error will be raised.

crates/vm/src/vm/vm_new.rs (1)

603-603: LGTM! Follows established pattern for exception factory methods.

The new constructor is consistent with existing exception factory methods like new_runtime_error and new_recursion_error, using the same define_exception_fn! macro pattern.

crates/vm/src/exceptions.rs (5)

496-496: Field declaration follows established ordering.

Placed correctly after recursion_error within the RuntimeError subclass group.

---

808-808: Initialization follows established pattern.

The init_builtin_type() call is correctly placed after recursion_error initialization, maintaining consistency with the ExceptionZoo field ordering.

---

884-884: Struct field assignment is consistent.

Correctly placed in the same relative position as the field declaration and initialization.

---

998-1002: Extension registration follows established pattern.

The extend_exception! macro call correctly registers PyPythonFinalizationError without any additional attributes, which is appropriate for this simple exception type.

---

2122-2125: LGTM! Exception type correctly subclasses PyRuntimeError.

The implementation follows the established pattern for simple exception types, matching the structure of PyNotImplementedError and PyRecursionError. All registration steps are complete and consistent across the ExceptionZoo struct, initialization, assignment, and macro extension.

Note: PythonFinalizationError was introduced in Python 3.13 (not 3.12) as a subclass of RuntimeError.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

• X
• Mastodon
• Reddit
• LinkedIn

Comment @coderabbitai help to get the list of available commands and usage tips.