Current format in an artifact compiled with the default solcjs

"compiler": {
    "name": "solc",
    "version": "0.4.21+commit.dfe3193c.Emscripten.clang" 
  },

    settings: {
      optimizer: options.solc.optimizer,
      outputSelection: {
        "*": {
          "*": [
            "abi",
            "ast",
            "evm.bytecode.object",
            "evm.bytecode.sourceMap",
            "evm.deployedBytecode.object",
            "evm.deployedBytecode.sourceMap"
          ]
        },
      }
    }

The ast is not an output of a given contract, but a file, therefore it will not be matched against *. Please see the documentation regarding this.

The correct version should be:

    settings: {
      optimizer: options.solc.optimizer,
      outputSelection: {
        "*": {
          "": [
            "ast"
          ],
          "*": [
            "abi",
            "evm.bytecode.object",
            "evm.bytecode.sourceMap",
            "evm.deployedBytecode.object",
            "evm.deployedBytecode.sourceMap"
          ]
        },
      }
    }

The bytecode generated by truffle compile and the bin generated by solc are always different.

I am using:

• solc v0.4.24
• truffle v4.1.14 (which, according to its package.json, relies on solc v0.4.24)

It appears that the difference is always in the 64 characters which appear right before the last 4 characters in each output. Is that possibly just metadata?

Anyhow, you can reproduce this as follows:

Input file MyContract.sol:

pragma solidity 0.4.24;
contract MyContract {
    uint public x = 42;
}

Truffle command-line:

truffle compile

Solc command-line:

solc --bin --output-dir=build/contracts contracts/MyContract.sol

Truffle output file MyContract.json:

{
  ...
  "bytecode": "0x6080604052602a600055348015601457600080fd5b50609e806100236000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630c55699c146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600054815600a165627a7a7230582085d8b01651d23ddd6a24f980e190a61c86b692278463007d8ac2f5c74d4693100029",
  ...
}

Solc output file MyContract.bin:

6080604052602a600055348015601457600080fd5b50609e806100236000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630c55699c146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600054815600a165627a7a72305820f18509eb242360daf2e9973ce555fa9a12f0e24589132507643b11daeef3e0440029

The difference:

T: 6080604052602a600055348015601457600080fd5b50609e806100236000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630c55699c146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600054815600a165627a7a7230582085d8b01651d23ddd6a24f980e190a61c86b692278463007d8ac2f5c74d4693100029
S: 6080604052602a600055348015601457600080fd5b50609e806100236000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630c55699c146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600054815600a165627a7a72305820f18509eb242360daf2e9973ce555fa9a12f0e24589132507643b11daeef3e0440029

When files in the /contracts/ directory of a truffle project collectively contain more than one contract with the same contract name, Truffle seems to choose which one to compile in a random or alternating fashion (I haven't yet dug deep enough to see exactly how that gets determined now). This means that running what seems to be the same thing twice in sequence can produce different results, if the contents of the contracts in the different files differ.

This can be very hard to debug, because the programmer may not be modifying the files that get used when running, as which file(s) those are change from run to run in a way that is not obvious or intuitive for the programmer.

The appearance of this issue can be attributed to user error, in that ideally such a name collision should not occur. However, some version control systems can produce this situation. For example, Subversion occasionally drops in older revisions when it detects a potential conflict, and the "poor man's version control" of keeping multiple copies of a file with differing filenames to track progressive versions (or to build an MCVE diff for a bug report) would also produce this issue, when those copies are kept in the same directory. I don't advocate for either of those two methods (generally, go with git) but they do get used.

As a heuristic that I think will generally match programmer intent, I suggest that when the set of files being compiled contains contract name collisions, the contract from the file with the latest modified date[time] should be used. If there is an exact tie for file modification date, I suggest using the one from the file with the fewest number of contracts (to encourage modularity), the one which occurs later in a file if both are in the same file (like CSS), the longer one (contracts tend to grow more often than shrink during at least early development), and finally the one with the lowest hash value, as tiebreakers. If there's still a tie by that point, the status quo solution should be OK.

This will make compilation more deterministic and predictable, to facilitate debugging.

See discussion at #64.

In that PR solcjs is used to run parseImports. We might be able to do this using the native compiler more quickly if we re-org things a bit. . . Also see #36 and make sure we're doing what is advised there.

Every nightly release emits this warning: "Warning: This is a pre-release compiler version, please do not use it in production."

Unfortunately that means they cannot be used with truffle as warnings are considered errors in truffle.

It would be really nice making an exception for that given warning. This is currently blocking testing within Solidity unfortunately.

See ethereum/solidity#3244 for more details.

compile current doesn't support a way to know what contract names are required and thus is required to always use * in the output selection of Solidity's interface: https://github.com/trufflesuite/truffle-compile/blob/master/index.js#L71-L72

Problematic dependencies:

• [email protected] broken due to trufflesuite/truffle-config#2
• [email protected] broken due to transitive dependency on [email protected], see https://github.com/trufflesuite/truffle-contract/issues/31

http://truffleframework.com/docs/advanced/configuration#solc

This documentation is incorrect. The only thing configurable is the optimizer.

It's two major version behind

solc 0.4.8 has some issues with source files which do not contain a contract or library with the same name as the filename. I recommend bumping the version of solc

From ConsenSys slack:

alanlu [6:05 PM]
Speaking of EthPM and ERC20, I have been getting this error: Could not find expected contract or library in 'example-package-standard-token/AbstractToken.sol': contract or library 'AbstractToken' not found.

[6:06]
Truffle v3.1.1 from NPM, using truffle install example-package-standard-token

[6:09]
Stuff compiles if I go into installed_contracts and rename Token to AbstractToken everywhere, but obviously, that's not a solution, so I was wondering if anybody knows about anything? As far as I can tell, Solidity docs do not suggest any naming restriction wrt contracts and filenames.

mike [6:10 PM]
@ alanlu this is a solc bug. Fixed in 0.4.9.

[6:10]
Which isn’t in Truffle yet.

This doesn't work:
https://github.com/trufflesuite/truffle-compile/blob/master/profiler.js#L253-L254

If a contract has a syntax error, you don't get the file name and line number where it was found.
Try running truffle publish on this project: https://github.com/OpenZeppelin/zeppelin-solidity/tree/72d31c2471f1f6eadeec63391e6f9003dddc52f4

parseImports currently tries to parse the file names from error messages. It would be much more reliable to use the import callback the compiler provides:

compilerStandard(json, function (path) { ...})

The function will need to return either { error: "Error message" } or { contents: "<file contents>" }.

(Moved from trufflesuite/truffle#839)

• I've asked for help in the Truffle Gitter before filing this issue.

Issue

Modifying a base contract doesn't trigger recompilation of derived contracts.

Steps to Reproduce

1. Copy Alpha.sol and Beta.sol from ethereum/solidity#3675 to a new Truffle project's contracts directory.

2. In the project directory, truffle compile.

3. To Alpha.sol, add the following before the final closing curly brace:

    function newFunctionInBaseContract(uint newValue) public {
        secondField = newValue;
    }
   

4. In the project directory, truffle compile again, as many times as you want.

5. Inspect ABI of Beta in build/contracts/Beta.json.

Expected Behavior

The output from truffle compile should be:

Compiling .\contracts\Alpha.sol...
Compiling .\contracts\Beta.sol...
Writing artifacts to .\build\contracts

ABIs in Alpha.json and Beta.json should both contain newFunctionInBaseContract.

Actual Results

The output from truffle compile is:

Compiling .\contracts\Alpha.sol...
Writing artifacts to .\build\contracts

and while Alpha.json contains the ABI including newFunctionInBaseContract, Beta does not.

Environment

• Operating System: Windows 10
• Ethereum client: N/A
• Truffle version (truffle version): Truffle v4.0.4 (core: 4.0.4)
• solidity version: Solidity v0.4.18 (solc-js)
• node version (node --version): v9.3.0
• npm version (npm --version): v5.6.0

Truffle is currently stuck with 0.4.19, the last release was 0.4.21 and 0.4.22 planned within the next two weeks.

A lot of warnings are introduced for things which are going to be errors in 0.5.0. If these 0.4.x releases are not rolled out in time to the users there will be a bigger shock receiving 0.5.0.

Please update to 0.4.21 😉

I think there is no way to choose a solc version. This could be set up in the truffle.js file:

{
   compiler: {
      version: "0.4.8",
      optimization: false
  }
}

Hi,

According to this line, seems like it's possible to silent all the warning when compiling the contracts.

But, it didn't worked for me. I have tried many ways:

$ truffle compile -quiet
$ truffle compile --quiet
$ truffle compile --quiet=true
$ truffle compile --quiet="true"
$ truffle compile --quiet true
$ truffle compile --quiet "true"

Adding the quite key inside truffle.js file also didn't work for me:

development: {
      quiet: true,
      host: "127.0.0.1",
      port: 7545,
      network_id: "*" // match any network
}

All of above commands didn't work for me. Any pointers?

Thanks.

Recent compiler versions introduced evmVersion as a setting in the JSON. If the field is missing, it defaults to byzantium which enables the use of returndatacopy. This has caused some issues with non-compliant ERC20 token contracts (see ethereum/solidity#4116 for more).

Other options include homestead, spuriousDragon and tangerineWhistle. It would make sense to support this option so that those requiring it could resort to the old, unsafe, behaviour.

There's a tuning about optimization loops in

but, since this modification it's not a default in solcjs, and it is not warned there's no way to verify the code in etherscan once deployed.

I sent a email to etherscan about supporting this compilation flag, too.

Overlooked this in the initial work. Solcjs has a feature we use to get import paths that's missing from the command-line compilers. Believe the simplest solution is to continue to use solcjs for this, but we'll likely need to fetch a js solc that matches the selected native version.

Think this import path collection is fast (there's a note to that effect in the code). It's not a real compilation? Need to check that out too.

I write an abstract contract interface like so:

contract MyContract { function foo() public { }

Uh, oh! Typo! Fortunately the compiler will catch it for me...

/usr/local/lib/node_modules/truffle/node_modules/truffle-compile/profiler.js:120
if (ancestors.length > 0) {
^

TypeError: Cannot read property 'length' of undefined
at walk_from (/usr/local/lib/node_modules/truffle/node_modules/truffle-compile/profiler.js:120:22)
at Array.forEach (native)
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/profiler.js:129:13
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/profiler.js:228:7
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/node_modules/async/dist/async.js:843:16
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/node_modules/async/dist/async.js:4956:25
at apply (/usr/local/lib/node_modules/truffle/node_modules/truffle-compile/node_modules/async/dist/async.js:21:25)
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/node_modules/async/dist/async.js:56:12
at /usr/local/lib/node_modules/truffle/node_modules/truffle-compile/profiler.js:191:18
at /usr/local/lib/node_modules/truffle/node_modules/truffle-resolver/index.js:77:5
at /usr/local/lib/node_modules/truffle/node_modules/truffle-resolver/node_modules/async/internal/onlyOnce.js:12:16
at /usr/local/lib/node_modules/truffle/node_modules/truffle-resolver/node_modules/async/whilst.js:63:18
at apply (/usr/local/lib/node_modules/truffle/node_modules/lodash/_apply.js:15:25)
at /usr/local/lib/node_modules/truffle/node_modules/lodash/_overRest.js:32:12
at /usr/local/lib/node_modules/truffle/node_modules/truffle-resolver/index.js:62:7
at /usr/local/lib/node_modules/truffle/node_modules/truffle-resolver/fs.js:41:12

waht

The compilation of smart contract is successful but the bytecode generated is just 0x.

Hi Guys,

We develop code linter that provide:

1. Strict source code validation according Solidity Style Guide
2. Security code check using ConsenSys Guide for Smart Contracts
3. Best practices code validation

We think that it would be very helpful for community to integrate capabilities of our linter to truffle.

We may create a PR. What do you think?

Thanks!
- Ilya