Contributing

Solang is in active development, so there are many ways in which you can contribute.

  • Consider that users who will read the docs are from different background and cultures and that they have different preferences.

  • Avoid potential offensive terms and, for instance, prefer “allow list and deny list” to “white list and black list”.

  • We believe that we all have a role to play to improve our world, and even if writing inclusive doc might not look like a huge improvement, it’s a first step in the right direction.

  • We suggest to refer to Microsoft bias free writing guidelines and Google inclusive doc writing guide as starting points.

How to report issues

Please report issues to github issues.

How to contribute code

Code contributions are submitted via pull requests.

Please fork this repository and make desired changes inside a dedicated branch on your fork. Prior to opening a pull request for your branch, make sure that the code in your branch

  • does compile without any warnings (run cargo build --workspace)

  • does not produce any clippy lints (run cargo clippy --workspace)

  • does pass all unit tests (run cargo test --workspace)

  • has no merge conflicts with the main branch

  • is correctly formatted (run cargo fmt --all if your IDE does not do that automatically)

Target Specific

Solang supports Polkadot and Solana. These targets need testing via integration tests. New targets like Fabric need to be added, and tests added.

Debugging issues with LLVM

The Solang compiler builds LLVM IR. This is done via the inkwell crate, which is a “safe” rust wrapper. However, it is easy to construct IR which is invalid. When this happens you might get segfaults deep in llvm. There are two ways to help when this happens.

Build LLVM with Assertions Enabled

If you are using llvm provided by your distribution, llvm will not be build with LLVM_ENABLE_ASSERTIONS=On. See Building LLVM from source how to build your own.

Verify the IR with llc

Some issues with the IR will not be detected even with LLVM Assertions on. These includes issues like instructions in a basic block after a branch instruction (i.e. unreachable instructions).

Run solang --emit llvm -v foo.sol and you will get a foo.ll file, assuming that the contract in foo.sol is called foo. Try to compile this with llc foo.ll. If IR is not valid, llc will tell you.

Style guide

Solang follows default rustfmt, and clippy. Any clippy warnings need to be fixed. Outside of the tests, code should ideally be written in a such a way that no #[allow(clippy::foo)] are needed.

For test code, this is much less strict. It is much more important that tests are written, and that they have good coverage rather than worrying about clippy warnings. Feel free to sprinkle some #[allow(clippy::foo)] around your test code to make your merge request pass.