Closed odesenfans closed 4 months ago
A few points of attention for the review:
get_builtins_final_stack
appears to be used in tests only, I wonder if that function is still relevant. I duplicated the change made in read_return_values
as it seemed pertinent, but I may be missing some context.get_output_unordered_builtins
test does not seem to make sense so I disabled it. If I understand this correctly the test checks if a program can specify its builtins out of order, but that seems like a silly idea. Might have misunderstood though, I didn't want to disassemble the program to check.I pushed a fix. The borrow checker was being a bit zealous for some reason.
Attention: Patch coverage is 98.26087%
with 2 lines
in your changes are missing coverage. Please review.
Project coverage is 96.56%. Comparing base (
ca3b8ab
) to head (0bcc83c
).:exclamation: Current head 0bcc83c differs from pull request most recent head ed23efc. Consider uploading reports for the commit ed23efc to get more accurate results
Files | Patch % | Lines |
---|---|---|
vm/src/vm/runners/cairo_runner.rs | 98.26% | 2 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@odesenfans can you check the comments by @fmoletta ?
This has been fixed by #1703
Problem: when using
allow-missing-builtins
for a program, some builtins requested by the program may not be part of the layout. This results in an incorrect configuration of the initial stack of the program as the program will expect pointers for all builtins, even though it may not access them later down the line. An example of this is any program that invokes another program (ex: the bootloader).Solution: copy the Python VM implementation. We now iterate over the program builtins and set the initial stack of the builtin if it is set up in the VM and a default value of (0, 0) otherwise.
Fixes #1631.
Checklist