feat: add parseJson helper functions

[odyslam]

Helper functions that leverage the new parseJson cheat code and enable the user to easily parse forge script artifacts.

The Structs will probably change a bit, due to the artifacts requiring some changes to avoid Solidity keyword keys and make the artifacts be consistent (produce keys with null values instead of omitting them)

[mds1]

Now that vm.parseJson is merged (thanks a lot @odyslam!) let's revisit this PR and get the required Vm interface updates, types, and any helpers merged

[odyslam]

1. Blocked on fix: address false positive foundry#2914
2. Currently, for some reason, a particular Receipt on the broadcast fixture is not decoded properly for unknown reasons.
3. readReceipt needs some refactoring, as it will result to stack too deep error unless we use --via-ir flag

[odyslam]

All issues fixed and --via-ir is not required any more

[odyslam]

The ci fail is propably because they fix PR that was just merged has not be yet propagated

[mds1]

If I rebase locally against main all tests pass, seems this branch is missing the projectRoot cheatcode definition from #158, so let's try that and see if it fixes CI? Though the CI failure does seem different than missing projectRoot

[mds1]

This is looking awesome, thanks a lot for all the work!

[odyslam]

I addressed all your comments, except for the library. The parser needs the state to have a nicer UX. It also needs console2, vm, so the imports would get a bit funky.

What I can't reason about is the projectRoot thing and why locally it seems to be OK but the file in GH is not.

[mds1]

Let me clarify, StdJson.sol should contain the stdJson library as before

Makes sense.

and StdCheatsJson.sol should contain the StdCheatsJson abstract contract so we can merge it with StdCheats in the future without breaking changes.

But what's this? Duplicate functionality as an abstract contract instead of a library?

[ZeroEkkusu]

But what's this? Duplicate functionality as an abstract contract instead of a library?

No, we are going to move the problematic std-cheats there and remove the current content.

[ZeroEkkusu]

Essentially, we can't get Test to compile w/ older solc because the new std-cheats use struct decoding. We are going to move them to a separate component, StdCheatsJson and let users import it manually if they want to use it. Does that make sense? @mds1 @odyslam

[odyslam]

@ZeroEkkusu to be very clear. We can compile with the experimental pragma. The issue we seem to be hitting on some solc is decoding string[] and bytes[]

[mds1]

Ok, I think I follow:

// Library
function parseRaw(string memory json, string memory key)
function readUint(string memory json, string memory key)
function readUintArray(string memory json, string memory key)
function readInt(string memory json, string memory key)
function readIntArray(string memory json, string memory key)
function readBytes32(string memory json, string memory key)
function readBytes32Array(string memory json, string memory key)
function readString(string memory json, string memory key)
function readStringArray(string memory json, string memory key)
function readAddress(string memory json, string memory key)
function readAddressArray(string memory json, string memory key)
function readBool(string memory json, string memory key)
function readBoolArray(string memory json, string memory key)
function readBytes(string memory json, string memory key)
function readBytesArray(string memory json, string memory key)

// StdCheatsJson

// --- snip: all the custom structs ---
function readEIP1559ScriptArtifact(string memory path)
function rawToConvertedEIPTx1559s(RawTx1559[] memory rawTxs)
function rawToConvertedEIPTx1559(RawTx1559 memory rawTx)
function rawToConvertedEIP1559Detail(RawTx1559Detail memory rawDetail)
function readTx1559s(string memory path)
function readTx1559(string memory path, uint256 index)
function readReceipts(string memory path)
function readReceipt(string memory path, uint index)
function rawToConvertedReceipts(RawReceipt[] memory rawReceipts)
function rawToConvertedReceipt(RawReceipt memory rawReceipt)
function rawToConvertedReceiptLogs(RawReceiptLog[] memory rawLogs)
function bytesToUint(bytes memory b) internal pure returns (uint256){

and let users import it manually if they want to use it. Does that make sense

This is the part I was missing, I didn't realize we still had this requirement

[mds1]

I think with pragma experimental ABIEncoderV2; we can have this functionality and import it by default?

[odyslam]

@mds1 even with the flag, we seem not being able to compile for 0.7.6 due to the types I mentioned above. Didn't go into why.

[ZeroEkkusu]

Lemme check.

[mds1]

Ahh I thought it was a test/runtime error, not a compilation error

[ZeroEkkusu]

So, it works with ABIEncoderV2. I just tried decoding string[] inside a struct with 0.7.6 and it works as well. @odyslam

[odyslam]

My solc failed to compile. What the actual F

[ZeroEkkusu]

I was experimenting manually. Going to check out the PR now and compile it myself.

[odyslam]

Try to build from 7daae38

[ZeroEkkusu]

Ok, I see with 0.7.6. Looking into it.

[ZeroEkkusu]

@odyslam It's because it missing pragma experimental ABIEncoderV2;.

[ZeroEkkusu]

So, let's:

• revert the last commit
• add pragma experimental ABIEncoderV2; to StdJson.sol
• rename the library to stdJson and correct the name in StdCheatsTest
• address feat: add parseJson helper functions #138 (comment)
• merge

[odyslam]

@ZeroEkkusu I can't merge

[mds1]

Love to see it

Thanks so much @odyslam for getting this done, thanks @ZeroEkkusu for your help with review. @ZeroEkkusu this LGTM, feel free to squash merge if you wanted to do a final check

[odyslam]

Next steps:

• Address Artifact parsing
• Address LegacyTxs (transaction artifacts produced by non 1559 networks)

[ZeroEkkusu]

The reason CI didn't fail was because it is configured to use 0.7.0. Now, everything's compiling.

Great work, team!