Support RITE0400 bytecode and ensure handling - #90
Merged
Merged
Conversation
mruby 4.0 renumbered the opcode table from index 36 and added thirteen opcodes, so a 4.0 chunk cannot be decoded with the 3.x numbering and a 3.x chunk cannot be decoded with this one. rite::load now refuses any header that does not say 04, and the tests compile their Ruby with mruby-compiler2, which emits it. The table and the opcodes have to land together: 4.0's codegen reaches TDEF, SSEND0 and the RET* family for ordinary Ruby, so the existing suite would hit unimplemented arms if either half came first. The same goes for three paths 4.0's codegen walks that 3.3's did not: - a rescue handler opens with GETGV $! rather than EXCEPT, and reading a global that was never assigned answered an internal error instead of nil - a single begin/ensure emits three overlapping catch handlers, so the table has to keep each handler's range and be searched the way vm.c's catch_handler_find does, at the raise, innermost first - the ensure path runs RESCUE against the nil that EXCEPT leaves behind, where the VM assumed an exception MATCHERR raises NoMatchingPatternError, which the prelude now defines under StandardError. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FfoC7uMVr3d3VaxWFnaPFT
consume_ensure_block stashed every error into vm.exception and carried on to the RAISEIF it stops at, so op_jmpuw returned Ok, the run loop never started unwinding, and the catch handler search was skipped. The exception surfaced as a Rust error out of vm.run() instead of being rescued by the Ruby around it. mruby aborts the clause at the raise. Real exceptions now leave as Err, which is the ingress the run loop already has for them. Error::Break and Error::BlockReturn keep the old handling: they are control flow, not exceptions, and the Break arm reads a breadcrumb that the ensure clause never pushed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FfoC7uMVr3d3VaxWFnaPFT
Use the released crates.io package for RITE0400 test compilation. Co-authored-by: Codex <codex@openai.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.
Split from #89 with only the two commits that introduce RITE0400 decoding and ensure exception propagation.
Excluded from #89: the ENTER &nil block-rejection change, removal of 3.x binary examples, and documentation updates.
Validated with
cargo test --package mrubyedge.