feat(solc): Use IndexedPathBuf for CompilerInput Sources

[pyk]

Motivation

Based on foundry-rs/foundry#1283 it seems that Etherscan is not automatically detect main contract to be displayed as the first source on the list.

After learning how hardhat-etherscan verification works turns out that hardhat always place the main contract as the first key of the sources.

This behaviour is currently not possible in ethers-solc due to CompilerInput sources is using BTreeMap<PathBuf, Source>. When compiler input is serialized as JSON, it always ordered alphabetically (PathBuf default), not by their insertion order.

Solution

This changes propose Sources to be defined as BTreeMap<IndexedPathBuf, Source> instead of BTreeMap<PathBuf, Source>. IndexedPathBuf contains index field which we can use to determine how the key is sorted by just simply assign the index value.

In the case of verification, the sources key will be ordered by source code for main contract first then followed by the imported source codes.

Results:

• Contract Verified without IndexedPathBuf
• Contract Verified with IndexedPathBuf

(SimpleERC20 is on top of the list and followed by the imports)

PR Checklist

• Added Tests
• Added Documentation
• Updated the changelog

[mattsse]

it seems that this is primarily for verification?

Are there any other advantages, because this touches a lot of internal code and indexedpath is only needed for verification?

I've been thinking a bit about how to implement this, but haven't gotten around to writing it down yet.

What if we make the standard_json function return a new type that acts like a CompilerInput but seriealises with sorted sources? basically your IndexedPath apporach

the index would probably come from the graph, imported_nodes I think? So I think we can make sources: Vec<(PathBuf, Source), which is serialised as map

ref https://serde.rs/impl-serialize.html#serializing-a-sequence-or-map

[pyk]

it seems that this is primarily for verification?

Yess

Are there any other advantages, because this touches a lot of internal code and indexedpath is only needed for verification?

I believe this only useful for verification only

What if we make the standard_json function return a new type that acts like a CompilerInput but seriealises with sorted sources? basically your IndexedPath apporach

Do you mean standard_json return trait or just new struct that behave like CompilerInput?

I think if we can change the return of standard_json to serde_json::Value it will much simpler using json! macro (which can be deserialized to CompilerInput)

[gakonst]

Yeah I'd say let's try to make it sort only when serializing in a non invasive way if possible!

[pyk]

@gakonst ok, noted 🙇

[pyk]

replaced by #1169 , thanks @mattsse sorry I haven't finished this yet. i will pickup other foundry issues this weekend 🙇