fix: Box.getReg is method id 19; absent/out-of-range dynamic index is None#884
Open
mwaddip wants to merge 2 commits into
Open
fix: Box.getReg is method id 19; absent/out-of-range dynamic index is None#884mwaddip wants to merge 2 commits into
mwaddip wants to merge 2 commits into
Conversation
The v6 dynamic-register-access method Box.getReg was registered under method id 7 — the JVM's getRegMethodV5 slot. The real getRegMethodV6 (sigma-state 6.0.3 methods.scala) is method id 19, gated to v3+ trees. The mismatch broke both wire directions: JVM-serialized getReg MethodCalls (id 19) failed to parse (UnknownMethodId), and Rust-built ones serialized as id 7, which a JVM node resolves to the non-evaluable getRegV5. Mirror the JVM exactly: - getReg moves to method id 19 with min_version V3 (the MethodCall deserializer already rejects pre-V3 occurrences via min_version, matching JVM v5Methods which has no id-19 entry); - method id 7 stays registered as getRegV5 so trees carrying it keep deserializing at any version, with no explicit type args on the wire (JVM getRegMethodV5 has none) and no eval — a live occurrence errors at evaluation, matching the JVM's failed reflective lookup. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…f-range index JVM CBox.getReg returns None when the dynamic register index is negative or >= maxRegisters, and when the slot is valid but the register is not set; only a present register of the wrong type throws. The Rust eval errored on out-of-range indices instead (RegisterIdOutOfBounds via the i32 -> i8 -> RegisterId conversions), diverging from the JVM on the blessed Box.getReg_dynamic_index vectors. Map an unconvertible index to an absent register (None) and keep the wrong-type error. Regression tests drive the real path — parse the blessed vector tree bytes, then eval: present/absent/out-of-range/ negative/beyond-i8 indices, the wrong-type boundary, and the getRegV5 twins (live occurrence errors, dead-branch occurrence accepts). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Box.getReg(v6 dynamic register access) was registered under method id 7 — the JVM'sgetRegV5slot. The realgetRegMethodV6(sigma-state 6.0.3methods.scala) is method id 19, v3+ trees only. So JVM-serializedgetRegcalls failed to parse (UnknownMethodId(19, 99)), and Rust-built ones serialized as id 7, which the JVM resolves to the non-evaluablegetRegV5.Commit 1 mirrors the JVM method table:
getReg= id 19,min_versionV3; id 7 stays registered asgetRegV5— deserializes at any version, no explicit type args on the wire, no eval (a live occurrence errors, matching the JVM's failed reflective lookup).Commit 2 mirrors
CBox.getReg: an absent or out-of-range index (< 0or>= maxRegisters) yieldsNone; only a present register of the wrong type errors.