refactor(revm): leverage StorageSlot methods, where appropriate #899
Conversation
| self.storage | ||
| .entry(key) | ||
| .or_insert(StorageSlot::new_changed(value, U256::ZERO)) | ||
| .or_insert(StorageSlot::new(value)) |
There was a problem hiding this comment.
Yes, it is (I hope you're referring to the differences between the logic of new() and new_changed()).
Why create a "changed" StorageSlot, if its present_value is being changed to the very same value as its previous_or_original_value after the execution of .or_insert() - practically, making the StorageSlot instance lose its "changed" status?
FWIW, it's still kinda weird to have .present_value = value; happen after .or_insert(), but this was weird before, as well. Now, present_value is, at least, not set to U256::ZERO, just to be re-set to value right after this.
Or am I missing something here?
There was a problem hiding this comment.
I missed something, I just looked at the changed code and saw that it is different, but I didn't see that we override the present_value so it does not matter.
There was a problem hiding this comment.
No problem. Glad we're on the same page now! 🙌🏻
No description provided.