compilers icon indicating copy to clipboard operation
compilers copied to clipboard

[wip] compiler abstraction

Open klkvr opened this issue 9 months ago • 1 comments

This PR introduces following traits:

  • Compiler - wrapper around compiler executable (solc/vyper) with following associated types
    • Input - trait capable of generating a Vec<Self> from given Sources set
    • ParsedSource - parser which extracts semver requirements and imported files from a given source
    • CompilationError - errors returned by underlying compiler binary
    • Settings - compiler settings
  • CompilerVersionManager - factory of Compilers capable of getting compilers by version

This PR contains 2 implementations of Compiler: Solc which is slightly updated Solc struct, and Vyper which is a draft PoC impl always invoking vyper command without any version management.

Currently it's already possible to compile and use cache for Vyper sources if vyper is avaialble on host machine.

Open questions:

  1. Do we need Compiler::Error associated type? It requires additional generics on Results returned by ProjectCompiler which I am not sure we'll ever use.
  2. Right now all Project::compile* functions accept either Compiler or CompilerVersionManager. This makes API a bit more complex as earlier we'd just call project.compile() and it'd use svm to auto-detect compiler version. Perhaps it makes sense to add more helper fns/types?

Some parts of the code are ignored for now as they are not really used in the actual compiler pipeline. I'll work on making tests pass and adapting all code to changes.

Other general changes to types:

  • allowed_paths and include_paths are moved from Project to ProjectPathsConfig
  • some of the compiler output types were indexing paths via String, updated keys for those to PathBuf.
  • Solc now always required to keep a Version as we need it to configure all flags correctly.

klkvr avatar Apr 26 '24 15:04 klkvr

Solc now always required to keep a Version as we need it to configure all flags correctly.

this makes sense, a solc that can't resolve the version will also fail when compiling, so new(path) -> Result<Solc> is more useful imo

mattsse avatar Apr 26 '24 15:04 mattsse

@elfedy yep, I was keeping zkSync usecase in mind

We've decided to not make output artifact type generic for now as foundry can already benefit from generic Compiler returning artifacts of the same shape (Contract)

In the future this will be made generic and for zkSync case this can return a single artifact including zksolc and solc compilation output

klkvr avatar May 02 '24 17:05 klkvr