Tags: Acelogic/miden-vm
Tags
fix(assembly-syntax): ensure export attributes are serialized for Lib… …rary (0xMiden#2612)
fix: decorators not copied when calling procedures from statically li… …nked libraries (0xMiden#2459) * test: add reproduction tests for issue 0xMiden#2456 (DecoratorId out of bounds) Add test cases attempting to reproduce the "DecoratorId out of bounds" error reported in issue 0xMiden#2456 that was observed in miden-base's execute_tx_view_script test. The issue manifests when: - A call instruction follows certain operations (e.g., push.1.2) - During program execution (not compilation) - The error disappears when adding "drop drop" after the push Test files: - issue_2456_test.rs: Basic reproduction with simple procedures - issue_2456_miden_base_repro.rs: Closer reproduction of the miden-base scenario Note: All tests currently PASS on this branch. If the issue still exists in miden-base, it may require the specific transaction execution context that these simplified tests don't capture. These tests serve as a baseline for the issue reporter to verify whether the problem persists. Related: 0xMiden#2456 * test: rename test functions to include issue number 2456 Makes it easy to run all issue 2456 tests with: cargo test 2456 All 4 tests are now properly discoverable and filterable. * refactor: modify the test to reproduce the error * fix(assembly): remap decorator IDs when copying statically linked procedures When copying procedure subtrees from statically linked libraries in `MastForestBuilder::ensure_external_link`, decorator IDs were not being remapped to the target forest. This caused "DecoratorId out of bounds" panics when the fingerprint calculation tried to access decorators using IDs from the source forest. The fix follows the same pattern as `MastForestMerger::build_with_remapped_children`: 1. Collect all decorators from the subtree before copying nodes 2. Copy decorators to target forest, building a decorator ID mapping 3. Remap all decorator IDs (before_enter, after_exit, and op-indexed) when building nodes from the source forest Also cleaned up test files by removing tests that didn't actually reproduce the issue (they used inline procedures instead of library modules, so decorators were never copied from a separate forest). * refactor: eliminate code duplication in decorator remapping Created `core/src/mast/node_builder_utils.rs` with a generic `build_node_with_remapped_ids` function that both `MastForestBuilder` and `MastForestMerger` now use. The generic function accepts any types implementing `LookupByIdx` for node and decorator mappings, allowing both `BTreeMap` and `DenseIdMap` to work. Renamed `test_issue_2456_call_with_push_before` to `test_issue_2456_statically_linked_library_call` to better describe what triggers the bug: calling procedures from statically linked libraries. Updated test documentation to explain that the issue occurs because decorators aren't remapped when copying nodes from statically linked libraries. The test was loading CoreLibrary as a dynamic library but not using it. The misleading comment suggested we needed to avoid sys::truncate_stack to not require the core library, but we were already loading it anyway. The test now properly demonstrates the issue without any unnecessary dependencies - just a statically linked library with a procedure that gets called from the main program.
PreviousNext