`forge-std` `StdStorage.sol`

[allan-wei-tx]

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]

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 :)