Light clippy(fy)
#9473
Light clippy(fy)
#9473
Conversation
niklasad1
added
A0-pleasereview 🤓
| @@ -31,7 +31,7 @@ use ethereum_types::{H256, U256}; | |||
| use memory_cache::MemoryLruCache; | |||
|
|
|||
| /// Configuration for how much data to cache. | |||
| #[derive(Debug, Clone, PartialEq, Eq)] | |||
| #[derive(Copy, Clone, Debug, PartialEq, Eq)] | |||
There was a problem hiding this comment.
What are the reasons to add Copy trait here?
There was a problem hiding this comment.
It is 5 usizes (max 40 bytes) and follows
Generally speaking, if your type can implement Copy, it should
There was a problem hiding this comment.
I can change it ofc if you have other opinions!
|
Yes, I had some |
There was a problem hiding this comment.
Yes, I had some wasm-tests mismatches but I guess this is newer than master. Should I revert it to be on the safe side?
Seems fine to me as long as all tests pass :)
| None => break, | ||
| while let Some(first) = self.sparse.pop_front() { | ||
| match self.complete_requests.remove(&first.hash()) { | ||
| None => { self.sparse.push_front(first); break; } |
|
|
||
| match self.complete_requests.remove(&start_hash) { | ||
| None => break, | ||
| while let Some(first) = self.sparse.pop_front() { |
There was a problem hiding this comment.
I don't know this code so I don't know if it makes sense to change this code to speculatively pop and then re-adding if complete_requests.remove fails. Is the success path the most common?
There was a problem hiding this comment.
Good point, Andre!
I don't know either!
This was more a hack to get around having a reference and mutating at the same time!
I somehow convinced myself by
This queue has
O(1)amortized inserts and removals from both ends of the container
But now I realize that the Header struct is big (~600 bytes) so I will revert this thanks 🙌
5chdn
added
A8-looksgood 🦄
Ran
clippyand fixed some issues!