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
branchis 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.