refactor(Execution): Granular handles create/call,call_return,insert_call_outcome #1024
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.
Added more granular handler for execution. Splitting of the call flow into:
call
that returnsFrameOrResult
. if it is Frame, frame is pushed to stack, if it is result,insert_call_output
is called.call_return
that is called only when call frame is returned, it pops the frame from stack, consumes it and returnsFrameResult
insert_call_output
This is called always (except the last frame), the tip frame is used to apply the call frame result.This similar flow is made for crate calls.
create_first_frame
is removed,call
/create
is used, andfirst_frame_return
is renamedlast_frame_return
. Last frame return is still needed asinsert_call_output
applies the change to frame while we need to transform the FrameResult to return outside to Evm.This change is aligned with #996 where I want frame actions to be generic and set in the Handler.
This makes the Inspector not override handlers but just wrap them, this allows more composition of handlers where for example Optimism does not need to think about this and makes the Inspector more generic and usable