Question: decoupling the solidity-coverage from solc version?

[travs]

What do you think about allowing the user to specify the solc version being used?

The use-case would be a compiler regression that affects contracts, such as this one.

Of course, one can always downgrade/pin the solidity-coverage version, but features developed since then will be unavailable without getting the offending solc version as well.

One way to achieve this without dealing with different NPM packages may be using legacy solc versions, and specifying it in the .solcover.js file (though I have not tried this).

Anyway, let me know if this makes any sense to you :)

[area]

I agree that this would be a useful piece of functionality, but I don't think the responsibility lies with us to provide it. The solc version in our dependencies is a development dependency, and is only required for running the tests of solidity-coverage itself. During tests, the version of solc being used depends on how you're running your tests; for most users of solidity-coverage, I would expect that to be truffle, which seems unlikely to support this in the near term.

[travs]

@area
Ah, I misunderstood how solidity-coverage operates, but it makes more sense now.
I have had a similar issue with truffle, and you are right: this is actually more related to the test runner.

I will close it since it does not depend directly on this project.
Thanks for the reply 👍

[celeduc]

This is now possible in truffle v0.5.x.

in truffle config:

module.exports = {
  compilers: {
    solc: {
      version: <string> // A version or constraint - Ex. "^0.5.0"
    }
  }
}

https://truffleframework.com/docs/truffle/reference/configuration#solc