Different bytecodes for the same contracts

[sammyne]

Description

Bug

Given the same contracts file but different path, compile with solc generate different bytecodes

Expectation

The same contract manifest should produce the same bytecodes

Environment

• Compiler version: 0.5.7+commit.6da8b019.Linux.g++
• Target EVM version (as per compiler settings): No
• Framework/IDE (e.g. Truffle or Remix): No
• EVM execution environment / backend / blockchain client: No
• Operating system: Fedora 29

Steps to Reproduce

To ease the reproduction, I have make a repository as solidity-playground containing the relevant files below, and the steps for reproduce the problem found go as follows

0. Clone the repository and change into the repository directory

   git clone https://github.com/sammyne/solidity-playground.git && cd solidity-playground

1. In the root directory, compile the World contract described as contracts/World.sol with bytecodes output to current directory

   solc --bin --optimize contracts/World.sol -o .

   This should give us two files Hello.bin and World.bin containing bytecodes for the respective contracts

2. Change into the contracts folder, and compile the World.sol with bytecodes output to that folder

   solc --bin --optimize World.sol -o .

   This should also give us two files Hello.bin and World.bin containing bytecodes for the respective contracts

3. Comparison tells difference

   • Compare the Hello.bin and contracts/Hello.bin with diff would tell us difference
   • Compare the World.bin and contracts/World.bin with diff would tell us difference

[erak]

@sammyne Thanks for your report. I'll have a look!

[chriseth]

This is expected behaviour. The reason behind this is that depending on the paths used, import statements will behave differently. So the (relative) paths are exposed as the unique names of contracts when compiling. Since the bytecode contains the metadata information of contracts, this also affects the bytecode.

[rickbeeloo]

Same here, https://snowtrace.io/contractdiffchecker?a2=0x0804Dd62deb46F11cDf47997778527B067E0D054&a1=0xB43C0e6460DAE61280fd4e6E793ae43Ed72AFA57, only difference I saw is that one had optimization enabled and other one did not. Could this cause that?

[cameel]

These contracts are not identical. Parameters passed to the inherited constructor differ:

constructor() ERC20("WAVAXPrinter", "WAVAXP", 9) {

vs

constructor() ERC20("SonOfDAO", "SOD", 9) {

[rickbeeloo]

These contracts are not identical. Parameters passed to the inherited constructor differ:

constructor() ERC20("WAVAXPrinter", "WAVAXP", 9) {

vs

constructor() ERC20("SonOfDAO", "SOD", 9) {

Aah yeah sorry didn't mean it like that, I meant the overall bytecode is completely different while only the constructor is different in the human readable code

[cameel]

What specifically do you mean by "overall bytecode"? The compiler gives you separate bytecode for each contract it finds. So if constructor parameters are different, this particular contract will have different bytecode even if everything else in it is identical. Other contracts in the same compilation should have identical bytecode (if you ignore the metadata).

Please try to compile with --metadata-hash none (CLI) or metadata: {bytecodeHash: "none"} (Standard JSON). If you're still getting different bytecode with that and you're not on 0.6.12 and 0.7.0 (see #12281), please create a new issue and we'll look into that.