bug(`cheatcodes`): `vm.dumpState` inconsistent address ordering w.r.t. deployment order

[JuanCoRo]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (62cdea8 2024-07-23T00:19:34.618350138Z)

What command(s) is the bug in?

forge script

Operating System

Linux

Describe the bug

The order of the address entries in the JSON produced by vm.dumpState is inconsistent regarding the order in which the contracts are deployed.
In the example below, we orderly deploy counter0, counter1, and counter2, setting counterN.number() to N. However, the order of the accounts in the produced JSON is counter0, counter2, counter1.

Note that ordering the entries w.r.t. deployment order might be one of many suitable orderings (it could be ordered w.r.t. storage updates, for instance). However, keeping the deployment order in the JSON might maximize its readability.

Reproduction steps

1. forge init dumpState
2. Append the following function to test/Counter.t.sol:

   function multiple_counters() public {                                                                                               
       for (uint256 i; i <= 2; ++i) {                                                                                                  
           counter = new Counter();                                                                                                    
           counter.setNumber(i);                                                                                                       
       }                                                                                                                               
       vm.dumpState(string.concat(vm.projectRoot(), "/dumpState.json"));                                                               
   }

3. forge script ./test/Counter.t.sol:CounterTest --sig multiple_counters ; cat dumpState.json | jq .

Executing step 3 produces the following JSON containing the accounts in a different order than deployed (0, 2, 1 instead of 0, 1, 2):

{
  "0x2e234dae75c793f67a35089c9d99245e1c58470b": {
    "nonce": "0x1",
    "balance": "0x0",
    "code": "0x6080604052348015600f57600080fd5b5060043610603c5760003560e01c80633fb5c1cb1460415780638381f58a146053578063d09de08a14606d575b600080fd5b6051604c3660046083565b600055565b005b605b60005481565b60405190815260200160405180910390f35b6051600080549080607c83609b565b9190505550565b600060208284031215609457600080fd5b5035919050565b60006001820160ba57634e487b7160e01b600052601160045260246000fd5b506001019056fea2646970667358221220091e48831e9eee32d4571d6291233a4fdaaa34b7dced8770f36f5368be825c5264736f6c63430008190033",
    "storage": {
      "0x0000000000000000000000000000000000000000000000000000000000000000": "0x0000000000000000000000000000000000000000000000000000000000000000"
    }
  },
  "0x5991a2df15a8f6a256d3ec51e99254cd3fb576a9": {
    "nonce": "0x1",
    "balance": "0x0",
    "code": "0x6080604052348015600f57600080fd5b5060043610603c5760003560e01c80633fb5c1cb1460415780638381f58a146053578063d09de08a14606d575b600080fd5b6051604c3660046083565b600055565b005b605b60005481565b60405190815260200160405180910390f35b6051600080549080607c83609b565b9190505550565b600060208284031215609457600080fd5b5035919050565b60006001820160ba57634e487b7160e01b600052601160045260246000fd5b506001019056fea2646970667358221220091e48831e9eee32d4571d6291233a4fdaaa34b7dced8770f36f5368be825c5264736f6c63430008190033",
    "storage": {
      "0x0000000000000000000000000000000000000000000000000000000000000000": "0x0000000000000000000000000000000000000000000000000000000000000002"
    }
  },
  "0xf62849f9a0b5bf2913b396098f7c7019b51a820a": {
    "nonce": "0x1",
    "balance": "0x0",
    "code": "0x6080604052348015600f57600080fd5b5060043610603c5760003560e01c80633fb5c1cb1460415780638381f58a146053578063d09de08a14606d575b600080fd5b6051604c3660046083565b600055565b005b605b60005481565b60405190815260200160405180910390f35b6051600080549080607c83609b565b9190505550565b600060208284031215609457600080fd5b5035919050565b60006001820160ba57634e487b7160e01b600052601160045260246000fd5b506001019056fea2646970667358221220091e48831e9eee32d4571d6291233a4fdaaa34b7dced8770f36f5368be825c5264736f6c63430008190033",
    "storage": {
      "0x0000000000000000000000000000000000000000000000000000000000000000": "0x0000000000000000000000000000000000000000000000000000000000000001"
    }
  }
}

[zerosnacks]

Looks like an inadvertent regression introduced by #8445 as a fix of #8426

Also related: #8501

[mds1]

Note that ordering the entries w.r.t. deployment order might be one of many suitable orderings (it could be ordered w.r.t. storage updates, for instance).

I wonder if simply sorting alphabetically by increasing address (and similarly for slot numbers) is the most clear? You can have contracts selfdestruct and be redeployed, and storage writes might occur in contract A then B then A again, in which case an ordering based on either of those doesn't make much sense