Omar f51693cb9f Support multiple compiler versions (#92)
* Allow for downloader to use version requirements.

We will soon add support for the compiler version requirement from the
metadata files to be honored. The compiler version is specified in the
solc modes section of the file and its specified as a `VersionReq` and
not as a version.

Therefore, we need to have the ability to honor this version requirement
and find the best version that satisfies the requirement.

* Request `VersionOrRequirement` in compiler interface

* Honor the compiler version requirement in metadata

This commit honors the compiler version requirement listed in the solc
modes of the metadata file. If this version requirement is provided then
it overrides what was passed in the CLI. Otherwise, the CLI version will
be used.

* Make compiler IO completely generic.

Before this commit, the types that were used for the compiler input and
output were the resolc compiler types which was a leaky abstraction as
we have traits to abstract the compilers away but we expose their
internal types out to other crates.

This commit did the following:
1. Made the compiler IO types fully generic so that all of the logic for
   constructing the map of compiled contracts is all done by the
   compiler implementation and not by the consuming code.
2. Changed the input types used for Solc to be the forge standard JSON
   types for Solc instead of resolc.

* Fix machete

* Add resolc to CI

* Add resolc to CI

* Add resolc to CI

* Add resolc to CI
2025-07-30 04:56:23 +00:00
2025-03-07 09:25:39 +01:00
2025-03-31 16:44:16 +02:00

revive-differential-tests

The revive differential testing framework allows to define smart contract tests in a declarative manner in order to compile and execute them against different Ethereum-compatible blockchain implmentations. This is useful to:

  • Analyze observable differences in contract compilation and execution across different blockchain implementations, including contract storage, account balances, transaction output and emitted events on a per-transaction base.
  • Collect and compare benchmark metrics such as code size, gas usage or transaction throughput per seconds (TPS) of different blockchain implementations.
  • Ensure reproducible contract builds across multiple compiler implementations or multiple host platforms.
  • Implement end-to-end regression tests for Ethereum-compatible smart contract stacks.

Declarative test format

For now, the format used to write tests is the matter-labs era compiler format. This allows us to re-use many tests from their corpora.

The retester utility

The retester helper utilty is used to run the tests. To get an idea of what retester can do, please consults its command line help:

cargo run -p revive-dt-core -- --help

For example, to run the complex Solidity tests, define a corpus structure as follows:

{
    "name": "ML Solidity Complex",
    "path": "/path/to/era-compiler-tests/solidity/complex"
}

Assuming this to be saved in a ml-solidity-complex.json file, the following command will try to compile and execute the tests found inside the corpus:

RUST_LOG=debug cargo r --release -p revive-dt-core  -- --corpus ml-solidity-complex.json 
S
Description
No description provided
Readme Apache-2.0 34 MiB
Languages
Rust 96.6%
Python 2.9%
Shell 0.4%