trufflesuite / truffle

:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat?utm_source=github&utm_medium=referral&utm_campaign=2023_Sep_truffle-sunset-2023_announcement_
MIT License
14.02k stars 2.31k forks source link

Add support for custom compiler version #265

Closed chevdor closed 5 years ago

chevdor commented 8 years ago

Currently, the version ^0.3.5 of solc is used. The solidity compiler does not produce the same results depending on the on the version used. Dapp developpers may want to control which version is used.

The ability to provide a custom version in the config/as option would be great. Then use this version while invoking the solidity compiler as: var solcV011 = solc.useVersion('v0.1.1-2015-08-04-6ff4cd6');

rfikki commented 8 years ago

+1

tcoulter commented 8 years ago

In general I see this as a good feature. However, I'd guess you want this feature so you can bump the version up to solidity 0.4.x, right? If so, this solution will likely cause more problems than it solves.

The main reason Truffle hasn't been bumped up to version 0.4.x already is because of the introduction of breaking changes: Specifically the pragma statement. This is an issue because Truffle uses a library called solidity-parser in order to perform some preprocessing, and solidity-parser needs to be upgraded to support the pragma statement before you can use 0.4.x with Truffle. If you were to use the proposed feature to upgrade the version to 0.4.x, Truffle will error before compilation ever occurs.

Where this feature could be very useful is downgrading the compiler version, or setting a specific compiler version for testing purposes (aka, testing the compiler) or locking your project into a specific version. But it won't be able to go forward past the latest version Truffle supports (0.3.5 in this case). If we implement this feature, we need to ensure we don't allow users to go higher than the latest version supported as that will cause unexpected errors.

To better understand your use case, why do you want to specify the version?

chevdor commented 8 years ago

Actually, the main reason is not only 0.4.x but exactly what you mentioned about the downgrading.

Compilers do not behave the same, so while it is advised using the latest, sometimes, people prefer to use a given (older) version.

The 0.4.x example you mention is a good one, we should use 0.4.x, but for now we don´t (whatever the reasons are).

I think it would be fair to have such feature, and as you suggest, lock it down, at least for now, to a given set of versions (ie everything < 0.4.x)

To avoid any extra issue reports, I would specifically point to this ticket since you now nicely explained why 0.4.x cannot yet be working :)

area commented 7 years ago

Now that the main branch is on 0.4.x, can this be revisited? Solidity 0.4.8 breaks contracts generated by Solcover, so it would have been nice to have this feature to force people to use 0.4.7 until 0.4.9 comes out (which won't have this problem).

vongohren commented 7 years ago

Any progress on this? Im trying to use 0.4.10, but my truffle is stuck on 0.4.8. Even if my solc --version is 0.4.10

tcoulter commented 7 years ago

A new version of Truffle with Solidity 0.4.11 will be released tomorrow (Monday). However, Truffle can't yet support custom compiler versions because of Solidity releasing breaking API changes on minor versions (generally considered a no no). For instance, in the last three versions (0.4.9 to 0.4.11), the API has changed twice; in order to keep Truffle from automatically breaking and preventing users from compiling at all, we have to lock down the compiler to a specific version.

We're unlikely to implement custom compiler version support until Solidity adopts better release practices, which will likely come as Solidity matures.

tcoulter commented 7 years ago

I'm going to close this issue as I don't see this feature being possible in the short term. Additionally, the desire for "custom compiler versions" generally translates to a desire for the latest version, which we try to stay on top of as much as possible. We didn't upgrade to 0.4.9 or 0.4.10 because of a breaking change to the compiler output that prevented Truffle from linking library contracts. Other tools were affected as well.

benjaminmbrown commented 6 years ago

I have a use case wherein I have a requirement to test a client's smart contracts written in previous compiler versions. Currently remix allows specification for any compiler version. Just thought I'd bring up this case where latest version is not always the desire.

cgewecke commented 6 years ago

@benjaminmbrown We've just started publishing an experimental build - truffle@byoc - which automatically pulls down any compiler you'd like from solc-bin. You just have to set a key in the truffle.js config specifying the version.

Usage docs

Install

npm install -g truffle@byoc

It's current with 4.1.12 - please report its bugs :)

aleybovich commented 6 years ago

@cgewecke Is this feature in the latest 5.0.1 beta? I just realized I need to compile abi's for multiple solc versions at the same time and looking for ways to do that.

gnidan commented 5 years ago

@aleybovich This is in the beta, but not what you're asking for. Truffle v5 supports specifying a single solc version to use, but does not support multiple simultaneous versions of solc natively.

Please feel free to open an issue for the "multiple versions" enhancement if you would like. In the meantime, closing this issue for maintenance. Thanks!