-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(forge): Optionally use create2 factory in tests and non-broadcasting scripts #6656
Conversation
Thanks for opening this! I agree this needs to be introduced in a way that avoids breaking changes, since it's likely users have assertions with hardcoded expected create2 addresses. What do you think about doing this as a config option / CLI flag instead? My rationale is that users are unlikely to only need this feature in a subset of tests, making a global flag simpler than a cheatcode, since a cheat might need to be declared in multiple places. And declaring a cheat in multiple places (since not all tests share the same setup) makes it more error prone / hard to be consistent everywhere. And we should remove this in v1 and make this the default for simplicity, cc @Evalir to document this wherever v1 breaking changes are being tracked Also cc @zobront who originally pointed out this issue |
I think that's a good idea. I've updated this PR. |
478e31b
to
ac45ba5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a smol nit:
crates/cheatcodes/src/inspector.rs
Outdated
|
||
fn process_create<DB: DatabaseExt>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add some docs on what the two functions do now? as we have apply_create2_deployer
and process_create
, and previously process_create
was fallible, but now it will always succeed and update state in case of scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Evalir Just bumping since this is ready for review. Thanks.
1c92c86
to
7b5da01
Compare
7b5da01
to
6ad0f7d
Compare
6ad0f7d
to
78130a2
Compare
78130a2
to
c2c2515
Compare
Hey @Evalir, this continues to be an issue for us. The PR has been ready for a month, so I just wanted to bump it. Totally understand you've got a lot on your plate, but I just want to make sure that this doesn't get buried into oblivion :) |
Understood @sam-goldman — let's fix this :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -1241,6 +1235,14 @@ impl<DB: DatabaseExt> Inspector<DB> for Cheatcodes { | |||
} | |||
} | |||
|
|||
// Apply the Create2 deployer | |||
if self.broadcast.is_some() || self.config.always_use_create_2_factory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the title says "non broadcasting scripts", but this applies the create2 deployer on broadcasting scripts only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intended to cause the create2 deployer to be applied in a broadcasting script, as is the current behavior. If the always_use_create_2_factory
is true, then the create2 deployer should also be used in tests and non-broadcasting scripts. This should be the default behavior in my opinion, but using an option ensures this change is backward compatible.
I believe this PR correctly implements that behavior, but I am new to Rust, so let me know if you think I'm misunderstanding something about the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as @mds1 said, I think this makes sense and this looks like an appropriate solution imo
any concerns @DaniPopes
I only have nits
sorry for the delayed review
Co-authored-by: Matthias Seitz <matthias.seitz@outlook.de>
03f1f8a
to
e28aa9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
excited to get this in! cc @mds1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Motivation
#5529
Solution
Resolves #5529 by adding logic to allow the default create2 factory to be used in tests and non-broadcasting scripts. I chose to make this change non-breaking by introducing a new config option / CLI flag
always_use_create_2_factory
, which must be set totrue
to enable this behavior.In the future, this option could be removed or changed relatively easily to make using the create2 factory the default behavior if a breaking change is acceptable.