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

forge-std StdStorage.sol #477

Open
allan-wei-tx opened this issue Nov 10, 2023 · 1 comment
Open

forge-std StdStorage.sol #477

allan-wei-tx opened this issue Nov 10, 2023 · 1 comment

Comments

@allan-wei-tx
Copy link

https://github.com/foundry-rs/forge-std/blob/37a37ab73364d6644bfe11edf88a07880f99bd56/src/StdStorage.sol#L50C27-L50C32
I ran into a problem lately regarding to stdStorage.finds, where I used a TransparentUpgradeableProxy contract in a project, and then run finds on the implementation contract which is the standard procedure, and I found the slot I wanted in my unit test, but what puzzled me was that the forge coverage failed because the slot couldn't be found. Then I dug deeper into the source code of StdStorage, and I found that during test phase, the lengths of the reads (bytes32[] memory reads,) = vm.accesses(address(who)); was 1 while the length was 4 during the coverage phase. and all 4 elements in reads array during coverage phase are exactly the same. So I'm wondering if the reads array should be deduped and if this is a potential bug?

@mds1
Copy link
Collaborator

mds1 commented Nov 13, 2023

forge coverage runs with no optimizer / no via-ir enabled, so if you were normally using via-ir, this would result in some semantic changes, but I don't think that should affect this. cc'ing @brockelmore as the StdStorage author for any insights here :)

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

No branches or pull requests

2 participants