-
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
Debugger Refactor #2: DebuggerArgs
#5753
Conversation
Co-authored-by: DaniPopes <57450786+DaniPopes@users.noreply.github.com>
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.
nice! let's fix conflicts before doing a deeper review
yep doing that now sorry sir |
did a self review, looks good to me @Evalir |
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.
need to look at this more closely, but some preliminary comments
let mut compiled_contracts = BTreeMap::new(); | ||
let mut sources = BTreeMap::new(); | ||
let mut sources = HashMap::new(); |
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 shuffles ordering—is ordering an issue here?
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.
We don't need ordering, so there should be better performances with a HashMap
Can leave as-is if not appriopriate for this PR
crates/forge/bin/cmd/script/build.rs
Outdated
@@ -346,5 +280,5 @@ pub struct BuildOutput { | |||
pub highlevel_known_contracts: ArtifactContracts<ContractBytecodeSome>, | |||
pub libraries: Libraries, | |||
pub predeploy_libraries: Vec<ethers::types::Bytes>, | |||
pub sources: BTreeMap<u32, String>, | |||
pub sources: HashMap<String, HashMap<u32, (String, ContractBytecodeSome)>>, |
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.
Almost sure this might cause linking problems, ordering might be important here
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 you please elaborate ? I'm not sure why ordering would matter because we map the sources from the artifact Id https://github.com/foundry-rs/foundry/pull/5753/files/466d24a4be210ff3be7b7eedb8e62c76e4630d6e#diff-fdebd782f78bd93139131fe4f614d8ab47564bceef84dd9a009483b0c5ac7b41R42
DebbugerArgs
DebbugerArgs
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.
Since we're refactoring this to make it better, I'm being extra nitpicky here
crates/common/src/compile.rs
Outdated
/// Id to map from the bytecode to the source file | ||
pub type FileId = u32; |
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.
please no public type aliases for primtive values. either make it private or add a new wrapper type.
and move to top of file
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.
I think that it's reasonable to just drop this type
This is good |
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 few more comments, need to do another pass on the linking section—sorry we're being nitpicky, we just really wanna improve this! great work so far
let calldata = if let Some(counterexample) = result.counterexample.as_ref() { | ||
match counterexample { | ||
CounterExample::Single(ce) => ce.calldata.clone(), | ||
_ => unimplemented!(), |
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.
will we resolve 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.
I don't know, I'm not sure how to handle this because everything has been shaped for one calldata
and here it messes things up to have a sequence of calls
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 do that in #3 ? Probably modify the single_fuzz
to take in a Vec<calldata, value>
to support sequence calls. Just noticed that the value is defaulted to 0 right now as well, might make it a bug
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.
I'm just not familiar how we can force the fuzzer to construct a sequence of calls
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.
nice, defer to @Evalir to get this over the line
Friendly ping @Evalir |
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 pending conflicts, sorry about that
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.
yep agreed with mattsse_—sorry for the rebasing work needed here
No it's all G, thanks for the thorough review ! |
DebbugerArgs
DebuggerArgs
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.
gg, sweet, happy that this is over the line! (let's merge on monday just in case)
* fuzz single refactor * add struct docs * Update crates/evm/src/fuzz/mod.rs Co-authored-by: DaniPopes <57450786+DaniPopes@users.noreply.github.com> * add docs and move types to types.rs * fmt * add new debugger args type * add minimal debugger-refactor changes * finish him! * fmt * remove TODO * minimal diff * apply review suggestions * add TODO * looks better * make ContractSources wrapper * add more docki docs * write file_id docs! --------- Co-authored-by: DaniPopes <57450786+DaniPopes@users.noreply.github.com>
Second and last part of #5547 (sorry, cannot do smoller)
Adding the new
DebuggerArgs
struct that all part of the code should comply with,Removing the
run_debugger
function that is ran fromforge script
Simpler way of mapping contract sources, see
ui::debugger::ContractSources
type