Conversation
src/opcodes.rs
Outdated
| "invalid" => INVALID, | ||
| "selfdestruct" => SELFDESTRUCT, | ||
| &_ => panic!("Unknown opcode: {}", name), | ||
| &_ => JUMPLABEL, |
There was a problem hiding this comment.
treating anything else as a jump label feels wrong to me. we should probably parse it out correctly. maybe use the JumpLabelMap for that
There was a problem hiding this comment.
Agreed - this was more of a hotfix since otherwise it would error out. Will check out JumpLabelMap
|
Great! Lets split this into 2 PRs. I think the alt comments we can merge in. |
src/opcodes.rs
Outdated
| pub pops: usize, | ||
| pub pushes: usize, | ||
| pub sign: Option<&'static str>, | ||
| pub alt: &'static str, |
There was a problem hiding this comment.
maybe we use a more descriptive term for "alt"
There was a problem hiding this comment.
Any ideas? Maybe something related to "return value" since it adds that to the stack rather than the entire function call
There was a problem hiding this comment.
Renamed to stack output and show stack output (in line with evm.codes terminology) - wdyt @shafu0x
|
Jumplabels hack removed from the pr |
…with evm.codes terminology
| show-stack-output: [--stack-output] | ||
| ``` | ||
|
|
||
| Note: this setting will add stack outputs to the stack where possible. For example, instead of adding `call(param1, param2, ..., param7)` it will add `success` to the stack comments. |
There was a problem hiding this comment.
maybe we show both states of possible outcomes. So success | failure or 0 | 1. Because we don't actually know if it fails or not.
2 participants
Show stack output: some comments are quite long and cumbersome to read (eg call(param1, param2, ..., param7) so users can provide an optional
--stack-outputflag to override these with alternative values (in this casesuccesssince that is what is pushed to the stack after a call)