Skip to content

generic Executor and EvmEventLogger#5640

Closed
aathan wants to merge 1 commit intofoundry-rs:masterfrom
aathan:inline_logs2
Closed

generic Executor and EvmEventLogger#5640
aathan wants to merge 1 commit intofoundry-rs:masterfrom
aathan:inline_logs2

Conversation

@aathan
Copy link
Contributor

@aathan aathan commented Aug 15, 2023

Motivation

See #5505

Solution

@aathan
Copy link
Contributor Author

aathan commented Aug 16, 2023

Please look for the NOTE: in crates/evm/src/executor/inspector/logs.rs diff

Copy link
Member

@Evalir Evalir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to review this a bit more carefully, as it's a design change, but overall it doesn't seem unreasonable. I'd love your eyes @mattsse as well!

Some(token) => {
node_info!(
" Error: reverted with custom error: {:?}",
" Error: reverted with custom error (1): {:?}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
" Error: reverted with custom error (1): {:?}",
" Error: reverted with custom error: {:?}",

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI the point of this is to differentiate the source of the error. anvil's errors are sometimes formatted exactly the same but originate in different places.

None => {
node_info!(
" Error: reverted with custom error: {}",
" Error: reverted with custom error (2): {}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
" Error: reverted with custom error (2): {}",
" Error: reverted with custom error: {}",

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI the point of this is to differentiate the source of the error. anvil's errors are sometimes formatted exactly the same but originate in different places.

@aathan
Copy link
Contributor Author

aathan commented Aug 23, 2023

@Evalir I incorporated your requests. Listen, I've spent way too much time rebasing this pull request over and over. Please go ahead and make any trivial changes or comment suggestions you have and either accept or reject the PR. Waiting for me to respond to fairly trivial comments and having 40 commits happen in the meantime, such that I have to review all the deltas again is just not worth it.

As I mentioned in the original PR this is really about causing Executor to be generic, and having spent a little more time with the code, it's really InspectorStack itself that probably should be the generic type variable. ONLOG after all is basically looking to modify the per-call behavior of one of the inspectors in the InspectorStack.

The new commits I pulled show that you guys have now added an ExecutorBuilder. And really there already was what amounted to an InspectorStackBuilder (that's what InspectorStackConfig.stack() was doing) ...

What I'm getting at is that the specific inspectors and what their behaviors are is an integral part of definition the Executor, and what the specific behavior of each inspector in the inspector stack is, on a per tool basis (anvil, chisel, etc) should probably be embodied in a generic InspectorStack<... inspectors...>, which in my instant PR takes only the ONLOG generic which in turn modifies only the EvmEventLogger (formerly LogCollector).

The reason the current (and former) design is good 'nuf is that all the tools tend to share inspectors that all behave the same way across all the tools.

EDIT: To clatify, this instant change is a step in the right direction towards what is probably coming soon anyway i.e. generic for InspectorStack, so that inspector behavior within the Executor can be selected on a per-tool basis.

@Evalir
Copy link
Member

Evalir commented Sep 8, 2023

Hey, so, understood. Will close this PR for now—I think these are changes we definitely want, but we're undergoing a types migration and rebasing will just be a pain for either of us. Definitely agree this is a step in the right direction, and what we'll end up doing is probably getting these changes in after the migration.

Thanks for the contrib!

@Evalir Evalir closed this Sep 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants