Different bytecode Hardhat vs Sourcify

[kuzdogan]

We were reported a case when the compiled bytecodes end up different when compiled with Hardhat and with Sourcify. I suspect this is a case of ethereum/solidity#14250

meter-2707667c8a3e7035bf25c34ad0a1ec81.json.txt

Chain: Meter (82) Address: 0x07FfD62571b586dCA7eA1DC71C10a6270e078F01 Contract: N2MERC721

Onchain vs recompiled runtime bytecodes: 82-0x07FfD62571b586dCA7eA1DC71C10a6270e078F01-recompiled-deployed.txt 82-0x07FfD62571b586dCA7eA1DC71C10a6270e078F01-onchain-deployed.txt

They are different in many places:

git diff --word-diff --word-diff-regex=. 82-0x07FfD62571b586dCA7eA1DC71C10a6270e078F01-onchain-deployed.txt 82-0x07FfD62571b586dCA7eA1DC71C10a6270e078F01-recompiled-deployed.txt

_{View in Huly HI-479}

[kuzdogan]

I can confirm this gets resolved with useAllSources i.e. using all other sources provided alongside the contract.

However the bad news is this is not the ethereum/solidity#14250 case because I was able to reproduce the issue in 0.8.21 whereas the above issue must have been fixed in 0.8.21.

This looks similar to #618 because the metadata hashes are identical but the bytecodes are different. However, that specific case must also have been fixed in 0.7.1. So I suspect this is yet another bug in Solidity

[kuzdogan]

Opened an issue in Solidity ethereum/solidity#14494

[marcocastignoli]

I'm handling this cases in this way, if you also think is enough we can close this:

[kuzdogan]

Does this handle the example case above? Does the test pass?

[marcocastignoli]

fixed with f1be629