Skip to content
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

Merged
merged 19 commits into from
Sep 11, 2023

Conversation

iFrostizz
Copy link
Contributor

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 from forge script
Simpler way of mapping contract sources, see ui::debugger::ContractSources type

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.

nice! let's fix conflicts before doing a deeper review

@iFrostizz
Copy link
Contributor Author

yep doing that now sorry sir

@iFrostizz iFrostizz requested a review from Evalir August 30, 2023 22:20
@iFrostizz
Copy link
Contributor Author

did a self review, looks good to me @Evalir
there are less changes than it seems in the diff, git is not smart enough to show the correct diffs for lib.rs and make it look like there are many.

@iFrostizz iFrostizz changed the title Franfran/debugger args Debugger Refactor #1: DebbugerArgs Aug 30, 2023
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.

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();
Copy link
Member

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?

Copy link
Contributor Author

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

@@ -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)>>,
Copy link
Member

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

Copy link
Contributor Author

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

@iFrostizz iFrostizz changed the title Debugger Refactor #1: DebbugerArgs Debugger Refactor #2: DebbugerArgs Sep 2, 2023
@iFrostizz iFrostizz requested a review from Evalir September 2, 2023 10:00
Copy link
Member

@mattsse mattsse left a 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

Comment on lines 401 to 402
/// Id to map from the bytecode to the source file
pub type FileId = u32;
Copy link
Member

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

Copy link
Contributor Author

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

@iFrostizz iFrostizz requested a review from mattsse September 3, 2023 23:36
@iFrostizz
Copy link
Contributor Author

Since we're refactoring this to make it better, I'm being extra nitpicky here

This is good

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.

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!(),
Copy link
Member

Choose a reason for hiding this comment

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

will we resolve this?

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Member

@mattsse mattsse left a 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

@iFrostizz iFrostizz requested a review from Evalir September 4, 2023 18:34
@iFrostizz
Copy link
Contributor Author

Friendly ping @Evalir

Copy link
Member

@mattsse mattsse left a 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

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.

yep agreed with mattsse_—sorry for the rebasing work needed here

@iFrostizz
Copy link
Contributor Author

No it's all G, thanks for the thorough review !

@iFrostizz iFrostizz requested review from mattsse and Evalir September 8, 2023 17:48
@Evalir Evalir changed the title Debugger Refactor #2: DebbugerArgs Debugger Refactor #2: DebuggerArgs Sep 8, 2023
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.

gg, sweet, happy that this is over the line! (let's merge on monday just in case)

@Evalir Evalir merged commit 523354e into foundry-rs:master Sep 11, 2023
mikelodder7 pushed a commit to LIT-Protocol/foundry that referenced this pull request Sep 12, 2023
* 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>
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.

3 participants