Page tree
Skip to end of metadata
Go to start of metadata

Project Identifier

Solang, currently at version 0.1.0.

Sponsor(s)

  • Shawn Amundson <amundson@bitwise.io>
  • Silas Davis <silas@monax.io>
  • Greg Hill <greg.hill@monax.io>
  • Sean Young <sean@mess.org>

Abstract

Solang is a compiler for the Solidity language that can target ewasm (used by Hyperledger Burrow, future ethereum and others), Sawtooth Sabre, and Parity Substrate. It is written in rust and uses LLVM as the compiler backend. The aim is for full compatibility with the Solidity language where possible .

Once a compiler is written, other tooling can be written that depends on having compiler components available. Just like llvm is a compiler toolkit, Solang wants to be a Solidity toolkit. Linters, analysis tools, language servers, debuggers etc can be written by reusing the parsing/resolving phases of Solang.

Context

Solidity as a language does have its quirks, however it has established itself as a defacto language commonly used for smart contracts. Having Solidity support for the Hyperledger ledgers would be a great feature, conversely it would be beneficial for those projects to collaborate on a common compiler component.

Dependent Projects

Solang does not depend on any other project.

Motivation

The Ethereum Foundation has a Solidity compiler, which is a large C++ code base.  It contains a handwritten Solidity parser, and code optimizer. It can only target EVM on Ethereum. In the first instance, Solang is a new implementation of a Solidity compiler with modern tooling: written in rust, generated parser, targeting wasm, and using llvm for code gen. This makes the code base much smaller and makes it possible to compile Solidity for a range of ledger projects.

Once this is done, a range of new further tooling can built on top of this:

  • Improving the Solidity language itself, e.g. string processing or generics
  • Implement a Solidity Language Server for IDEs, see Create a new Solidity Language Server (SLS) using Solang Compiler
  • Integer overflow detection in Solidity
  • Link C code to Solidity using the LLVM Linker-as-a-library
  • Implement Solidity linter/style hints like rust clippy
  • Implement Solidity debug builds and debugger (using llvm debug codegen)
  • Static analysis tools
  • Formal methods
  • Generate EVM code using experimental evm llvm backend

Status

Solang would move into incubation, if approved.

Solution

Solang does not have complete language support yet. The language features which are supported are clearly documented. See: https://solang.readthedocs.io/

Solang tries to be a traditional compiler

  1. lexer
  2. parser (outputs: AST)
  3. resolver: (outputs: CFG)
  4. code emitter (output: LLVM IR)
  5. llvm wasm codegen
  6. linker

The layout of the source code is as follows:

src/parse/*

lexer and LALRPOP Solidity grammer

output: Abstract Syntax Tree

src/resolve/*

Resolves types, variables, functions etc

Generates control flow graph

src/emit/*

Converts Control Flow graph to LLVM IR

Has to do some tricks to generate PHI nodes

ABI encoder/decoder (eth/scale)

src/link.rs

Converts wasm object file to final wasm file

src/abi/*

Generates and reads ABIs

Efforts and Resources

This project is funded through a Web3 Foundation grant. In order to receive the grant, the project commits to a roadmap.  This roadmap means Solang will have full Solidity language support in fall 2020.

How To

The source code is hosted on github: https://github.com/hyperledger-labs/solang . Solang can compile Solidity for use with Hyperledger Burrow, and Hyperledger Sawtooth. How this can be done is documented: https://solang.readthedocs.io/en/latest/running.html

References

Closure

The aim is to provide great tooling for Solidity developers, whatever ledger they are using.  If developers start using our tooling, then we are succeeding.

Reviewed By


9 Comments

  1. This seems like a very worthy technical effort, so thanks for doing this Sean.  I guess the question of project incubation status comes down to how the TSC feels about small projects.  Are we OK accepting a project with only one core contributor (at least at this point)?  We should probably have this discussion orthogonally to discussing the technical merits of this proposal.

    By the way, the "Effort and Resources" section is usually a place where people list who will commit time to working on the project.  It's a great way to rope people into doing work!

    1. I second Hart's thoughts, so thanks Sean! I have the same question though, is one core contributor enough at this point?

      1. The project has a very high chance of success with a committed, knowledgeable, well funded and skillful person working with a modern toolset.  The scope of the project lends itself to this manner of working. Whether it needs to be a full fledged project is a different question.

        Please explain the advantages of being a full-fledged project in the Motivation section. What are the constraints of being a lab project?

        1. Hi Vipin,

          Thank you for your feedback. After speaking to everyone, I think your advice is totally correct: it is fine for Solang to remain in labs for now, and this is a great place for the project to grow.

          I appreciate the time you spent evaluating the proposal.

          Thanks,

          Sean

          1. As my Rust chops improve, I would like to look into contributing, especially on some low lying fruit. I will look into the github issues.

  2. Sean, can you update the list in the Reviewed By section to include the latest TSC members? If this came from the template, then Ry Jonesor Silona Bonewald should update the template.

    1. Unfortunately it looks like that's the previous TSC list