fix: bump openjd-rs crate deps to 0.4.0/0.5.2/0.5.2 - #335
Conversation
Sorry, something went wrong.
Signed-off-by: David Leong <leongdl@amazon.com>
| openjd-expr = "0.3.0" | ||
| openjd-model = "0.5.0" | ||
| openjd-sessions = "0.5.0" | ||
| openjd-expr = "0.4.0" |
There was a problem hiding this comment.
openjd-expr 0.3.0 -> 0.4.0 is a SemVer-breaking bump for a 0.x crate, and this PR changes no binding source. Two of the mirrored enums in rust-bindings/src/expr/profile.rs fail silently rather than at compile time, so neither cargo build nor the existing test suite would catch drift here.
1. ExprRevision — silent mislabeling. From<ExprRevision> for PyExprRevision (profile.rs:105-115) has a wildcard arm mapping any unknown upstream variant back to V2026_02, guarded by allow(unreachable_patterns). If 0.4.0 added a revision and moved ExprRevision::CURRENT to it, then ExprProfile() — which resolves to ExprRevision::CURRENT at profile.rs:395 — would build a profile on the new revision while the revision getter reports ExprRevision.V2026_02, and the Python ExprRevision.CURRENT classattr (profile.rs:61) would still be pinned to the old variant. The wildcard suppresses the non-exhaustive-match warning, so the build stays green. No test asserts the mapping either: test_equality.py:190 only compares CURRENT == CURRENT, and test_pickle.py:80 only round-trips the literal V2026_02 — both pass regardless. __repr__ at profile.rs:487-491 has the same wildcard.
2. ExprExtension — import-time panic. PyExprExtension::ALL (profile.rs:152-160) maps over ExprExtension::ALL through From<ExprExtension>, whose body is unreachable!("ExprExtension has no variants in this crate version") (profile.rs:178-183). If 0.4.0 shipped the first ExprExtension variant, this panics — and because ALL is a classattr, it fires during module import, not on first use.
Worth confirming against the 0.4.0 release notes that neither enum gained a variant. If they did not, consider replacing the ExprRevision wildcard with a loud failure — matching how ExprValue and TypeCode already handle this at expr_value.rs:179 and expr_type.rs:76 — so the next bump breaks the build instead of quietly reporting the wrong revision.
Sorry, something went wrong.
Picks up the crates published by openjd-rs#332.
No binding source changes were needed — openjd-expr 0.4.0's coercion split
(openjd-rs#329) does not touch any
API rust-bindings/ calls, so this is a pin bump, Cargo.lock, and the regenerated
THIRD-PARTY-LICENSES.txt.
Behaviour change worth a reviewer's attention
openjd-model #334 reaches Python
through deserialize_step, which the worker uses to rebuild a step:
silently dropped and expressions referencing those bindings failed with "Undefined variable").
now raises instead of being ignored:
ValueError: failed to deserialize Step: unknown field 'bogus', expected one of 'let', 'letBindings', 'actions', 'embeddedFiles'
Both verified against the rebuilt extension. The tightening is the only outward-facing
regression risk here; upstream shipped it as a patch release, hence fix: rather than feat!:.
Also in the pickup: list-parameter element coercion
(#335), symbol-table parameter
coercion (#330), list-to-string
element escaping (#336), and seven
overflow/panic/silent-wrong-value fixes (#321).
Testing
No xfail in test_known_gaps.py xpassed, so nothing needed re-homing.
Local hatch run test reports 93.98% against the 94% gate. That number is identical before and
after the bump (same missed lines with the 0.5.1 and 0.5.2 extensions) and comes from 24 tests
skipped in my environment, not from this change.