Share code construction and comparison controls - #9713

Summary

Align code-object construction, replacement, comparison and hashing controls with Python 3.15 through shared validation and existing binding primitives in two Rust production files.

• Compare constant keys before names and tables, releasing temporary keys left-to-right on both success and error.
• Compare retained Python name/local-plus/table objects through their protocols, preserving tuple/bytes-subclass callbacks instead of comparing normalized internal arrays.
• Hash the retained objects in CPython's order, preserving callback errors and the cached hash of the original constants tuple. Remove the local-partition count: code objects with identical combined locals-plus names can compare equal despite different local/cell partitions.
• Share CodeUnits' existing atomic deoptimization/cache traversal between byte serialization and hashing. Exclude inline caches and adaptive counters; hold the monitoring lock only after Python hash callbacks finish.

Validation

Compared against pinned CPython d220409a13b77de7a6c30abe16ea90db01528edc codeobject.c. The original four reference groups and nine expanded groups pass, covering callback order, early false/error exits, retained-field identity, local/cell partitions, original tuple hash caching and stable hashing after ordinary specialization. Constructed or modified code objects were not executed.

Independent source review passed, including bounds/traversal preservation, atomic reads, monitoring-lock scope and equality/hash consistency. Final threaded cargo check passed (1m04s), all-target Clippy passed (2m17s) with exactly the 12 unchanged baseline diagnostics, and normal commit hooks passed.

Limits and integration

Native RustPython execution remains unperformed because the required safety guard is not verified. External reference assertions and source review are not a native runtime pass; hosted CI remains necessary. No repository tests, markers, Lib files or workflows are changed.

The goal includes observable protocol callbacks and equality/hash consistency, not a promise of identical numerical hashes across distinct interpreter implementations. Signed constructor first-line representation differences remain outside this patch. #9688's filename repr work and #8939's constant-borrow ownership work remain separate and should be preserved on composition.

Integration with #9439 (head 95a4916) requires explicit reconciliation, not a clean automatic composition: retain that PR's removal of per-code monitoring data and its original_bytes-based deopt_code; omit this patch's extracted monitoring resolver and lock; hash through original_instructions_with with identity resolution. Its bounded base-instruction analysis helper has different stop semantics and should not replace serialization/hash traversal blindly. The retained-object comparison/hash controls are not duplicated by #9439.

Shared construction and replacement controls

• Share signed C-int conversion, original argument retention, audit-event construction, structural validation, name interning and CodeObject assembly. Existing derived signatures, ArgSpec, KwArgs and bind_for handle binding; no per-function keyword parser is added.
• Accept the constructor's optional freevars/cellvars tuples and positional-only signature. Convert replacement controls in declaration order and reject iterable substitutes for tuple fields without calling their iteration hooks.
• Emit the nine-value code.new audit event with original object identities and propagate vetoes at the constructor/replacement-specific phase. Retain numeric arguments through later callbacks. Snapshot the replacement's default filename before index conversion callbacks can mutate it.
• Keep constructor name normalization separate from replacement's exact-string validation, matching their distinct error precedence. Share argument/local-capacity validation and retain positive unknown flag bits. Preserve the original comparison/hash changes.

The constructor's negative firstlineno still uses the existing unsigned internal line representation. In-place interning of externally referenced tuples, constant deduplication and exact interned filename/name identity, malformed bytecode parity, generic binder TypeError wording, and broader locals/line representation changes remain outside scope. Existing safe bytecode checks and location-array behavior are retained; no constructed or replaced code is executed in reference probes. #6894's old locals representation redesign is not duplicated, but would require source reconciliation if revived.

The complete group currently changes 934 lines (+559/-375) in two production Rust files. Constructor-specific name diagnostics use native type names and the verified UTF-8-safe 500-byte bound. The added validation includes 103 focused and 103 independent pinned CPython cases, covering audit identity/veto/order, conversion and destruction order, structural errors, tuple subclass controls, mutable filename snapshots, flag retention and diagnostic bounds. Independent source review also confirmed that the original comparison/hash section is unchanged. These are reference checks and source review, not a claim that all oracle wording passes verbatim on RustPython.

Final follow-up validation: threaded host-env/VM/stdlib cargo check passed in 1m02s and all-targets Clippy in 2m20s, with exactly the 12 unchanged baseline diagnostics. The first compile exposed three borrowed-reference ownership conversions; those and two new lint findings were corrected, independently reviewed, and both final commands rerun. Normal commit hooks passed. Full workspace/C-API/native runtime and separate WASM/non-threaded graphs remain unexecuted.