Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Pranay Valson
    @area ah thanks!!
    Victor Vicente
    Hi everyone, I'm experimenting really long wait times between instrumentation and test beginning.
    I was investigating a little and I found that postProcessPure function loops over all *.sol files on the folder. We have flattened files for example there and I think thats the reason why this takes so long.
    Is it possible to use skipFiles and skipFolders on postProcessPure function like you are doing on instrumentTarget() or is it necessary parse all files?
    @VictorVicente Yes, there was a recent PR that did exactly this and it may work for your case. sc-forks/solidity-coverage#274
    Unfortunately it had to be reverted because there are some cases (notably Zeppelin) where it causes tests to fail. If you have a folder of flattened contracts that are checked into source control but unrelated to your tests this change should be safe though.
    Zeppelin has a large number of mock contracts they call libraries through which they don't want in the coverage report but which have to be post-processed. So the change in #274 needs to be made optional.
    If you have a chance could you test that locally and see if it speeds things up without breaking anything?
    Victor Vicente
    @cgewecke I'll try it and tell you what happened. We use Zeppelin too, so what I understood is that to make it work I shouldn't add Zeppelin files into skipFilesarray, is it ok?
    @VictorVicente I think it should be ok - it's only a problem for them when they're running their tests, which use the mocks. But lots of people who write libraries have to use this mock strategy because you can't call libraries directly in some circumstances....
    Victor Vicente
    @cgewecke It definitively solves flat folder problem. But now I have problems with 'oraclizeAPI.sol' file. I found that PR was related to this problem too so I was reading comments and testing.
    Are those changes safe too? Did you revert them too for any reason?
    Victor Vicente
    @cgewecke I tested with preproccessor-improvements branch code but it fails processing oraclizeAPI.sol code.
    I'm unit testing using this file so I really need to get it instrumented for the coverage report.
    So resuming, It would be really helpful if, as you said earlier, you make #274 changes optional by config and you include it in a new version.
    It won't solve oraclizeAPI.sol performance issue but I could workaround it if I can skip this file.
    Ok great @VictorVicente I will add that over the weekend. oraclizeAPI is known to be a serious problem for the coverage tool. It's written in a way that requires a huge number of recursive parsing steps to instrument correctly - for example many of its conditional statements are unbracketed and we have to modify that to execute branch coverage.
    Victor Vicente
    @cgewecke Great! I'll be waiting for the new version to skip oraclizeAPI until performance problems with it are solved.
    Stefan Arnaudov
    Hey, any suggestion on how to fix this pipeline - https://travis-ci.org/solidity-exercises/consensys-marketplace - all tests from running truffle tests pass, and when I run them with solidity-coverage some of them fail. I am using .call everywhere. Any other options?
    And I am getting "Error: VM Exception while processing transaction: revert" as an error
    @ArnaudovSt: rewriting .solcover.js to look like this worked for me. . . The upgradeability contracts have assembly that solidity-coverage interferes with. And you don't need the testrpc options in your case. It just works out of the box.
    module.exports = {
        skipFiles: ['abstractions', 'upgradeability']
    Screen Shot 2018-08-26 at 1.41.59 PM.png
    @VictorVicente Apologies for the delay getting to your issue but 0.5.10 now has a deepSkip: <boolean> option for .solcover.js which does what we discussed above.
    Victor Vicente
    @cgewecke Thank you!!! It is very useful for us
    hello! do you have plans to update ganache core and cli forks soon? finally there is version that returns revert codes and we already use it everywhere... updating this whole set of dependencies looks kind of complicated
    Hi @rudolfix. We updated relatively recently (sc-forks/solidity-coverage#273) and should be current with ganache-cli 6.1.6 / support revert with reason. Is it not working?
    Do you need more recent fixes?
    I think there was a bug there and in fact revert codes were not generated. At least I didn't manage to get them in that version. Ganache CLI v6.1.8 (ganache-core: 2.2.1) this one worked from the get go. revert codes are game changer in testing :) so yes if you could update the packages I'd be really grateful
    We have been using revert codes with solidity coverage at colony without issue, so there's something we're missing
    @rudolfix Can confirm what area says above . . . I think what's going on is that in 6.1.6 they started passing back the return data and Truffle V5 was able to do the message decoding on it's side. In 6.1.8 they decided to add the code to the error message string on the ganache side. trufflesuite/ganache-core@a04585c
    I guess we should upgrade ganache-core again because agree this really helpful.
    thank you! you are probably right. I'm using my own fork of truffle because it was lacking overloads.. we'll go back to main branch soon but upgrade of ganache-cli is really appreciated!
    Filip Małachowicz
    Hello! I've tried to update your package to the newest version of ganache-cli, but something is wrong for me. I created own fork of testrpc-sc (https://github.com/Exef/testrpc-sc ) which I updated using ganache-cli master branch. Next I build it, and published it to npm under https://www.npmjs.com/package/ethereumjs-testrpc-sc-fork. I used this as a new dependency of my fork of solidity-coverage (https://github.com/Exef/solidity-coverage/tree/develop). All test passes using new dependency, so for tests I pushed it to npm as https://www.npmjs.com/package/solidity-coverage-fork. I've also corrected all places that used solidity-coverage instead of solidity-coverage-fork (especially require.resolve in app.js). Unfortunately something goes wrong and my truffle package during running solidity-coverage command errors with Error: Cannot find module 'ethereumjs-testrpc-sc-fork/build/cli.node.js', cause there is no build folder inside of the node_modules/ethereumjs-testrpc-sc-fork.
    Hi there, thanks to the project maintainers for your great work on this project, I can't wait to get it integrated in our development. I'm using darq-truffle instead of truffle, and I can't get solidity-coverage to work. I've searched and tried various things to no avail, so I've opened this issue: sc-forks/solidity-coverage#304
    I just wanted to say hello đź‘‹and make myself available here in case I can help troubleshoot this issue faster. Thank you
    George Spasov
    @cgewecke Hey guys. George from etherlime here. Quite some time ago I had to change the library for keccak due to heavy installation issues of sol-cov as dependancy.
    Did noticed that I had no response to the PR
    youve probably missed it
    Can you please take a look at it
    I hate for etherlime to be pointing to our own fork repo
    Juwita W
    Hi guys, I'm facing error instrumenting when using solidity-coverage on my ERC-20 contract. It said There was a problem instrumenting ./coverageEnv/contracts/LearnToken.sol: SyntaxError: Expected ")", ",", "days", "ether", "finney", "hours", "minutes", "seconds", "szabo", "weeks", "wei", "years", comment, end of line, or whitespace but "*" found.
    on line above
    contract LearnToken is IBuyMechanism, BurnableToken, CappedToken(1200000000 * (10 ** uint256(18))) {
    Any idea how to resolve this beside changing 1200000000 * (10 ** uint256(18)) into 1200000000000000000000000000?

    Hey guys, are you already supporting payable addresses?
    Because when I run the coverage I get:
    Skipping instrumentation of ./coverageEnv/contracts/Migrations.sol Instrumenting ./coverageEnv/contracts/Owned.sol Cleaning up... There was a problem instrumenting ./coverageEnv/contracts/Owned.sol: SyntaxError: Expected ";", "=", comment, end of line, or whitespace but "p" found. Line: 7, Column: 21

    Really great that you put a tool out there for test coverage :)

    Good question @simonschmoll , I have the same issue with a contract I am working on.
    address payable public wallet; coverage error: There was a problem instrumenting ./coverageEnv/contracts/AbstractPaymentQuantum.sol: SyntaxError: Expected ";", "=", comment, end of line, or whitespace but "p" found. Line: 7, Column: 21
    As I can see it is not supported and the question would be if is there any solution for this at this moment?
    Stef Heyenrath
    @fpaun23 : I noticed the same. For now I did remove payable from my address.
    Stef Heyenrath

    I've troubles running coverage using:

    solidity-coverage 0.5.11
    Truffle v5.0.0-beta.2 (core: 5.0.0-beta.2)
    [Coverage] Solidity v0.5.0 (solc-js)

    I get an error like

    Error: while migrating Migrations: Returned error: Exceeds block gas limit
    [Coverage]     at ...\node_modules\truffle\build\webpack:\packages\truffle-deployer\src\deployment.js:364:1
    [Coverage]     at <anonymous>
    [Coverage]     at process._tickCallback (internal/process/next_tick.js:188:7)

    Example project can be found at : https://github.com/mstack/bootcamp-blockchain-smartcontracts/tree/master/Lab 2 in the Solidity folder.

    Stef Heyenrath
    It seems to work now. I did change some settings. If you want to know the details, take a look at that Lab 2 or Lab 4 solutions in that GitHub project.

    Hello, I am getting this error:

    Event trace could not be read.
    Error: ENOENT: no such file or directory, open './allFiredEvents'

    How can I fix this?

    Stef Heyenrath

    I fixed this by using nodetouch allFiredEvents

    Example coverage command:

    `"coverage": "npm run clean && nodetouch allFiredEvents && concurrently --names \"GanacheCLI,Coverage\" --kill-others \"node_modules\\.bin\\ganache-cli --quiet --port 8555 --gasPrice 0x01 --gasLimit 0xfffffffffff --allowUnlimitedContractSize\" \"node_modules\\.bin\\solidity-coverage\" || true",
    Guy Lando
    no matter what I do solidity-coverage runs out of gas (while normal test does not run out of gas). I even increased ganache gas limit to 40 million and truffle config coverage network gas limit to 20 million and still nothing helps. any ideas?
    transaction with 1,000,000,000 gas still ran out of gas
    Guy Lando
    solved by adding --allowUnlimitedContractSize parameter to testchain
    Hi there - running into an issue using 0.6.0-beta.5 and Solidity 0.5.8 where instrumentation is inserting events in require statements between the close parenthesis and the semicolon, i.e. require(value == true, "value cannot be false")<emit __BAD_INSTRUMENTATION_GOING_HERE>;
    Getting ParsedContract.sol:129:6: ParserError: Expected ';' but got 'emit'
    Any idea what could be causing this or how to go about fixing it? I wasn't hitting this error back when the contract was pared down a bit from its current size if it's any help