contributing.rst 2.0 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. Contributing
  2. ============
  3. Solang is in active development, so there are many ways in which you can
  4. contribute.
  5. Target Specific
  6. ---------------
  7. Solang supports Substrate and Solana. These targets need testing
  8. via integration tests. New targets like
  9. `Fabric <https://github.com/hyperledger/fabric-chaincode-wasm>`_ need to be
  10. added, and tests added.
  11. How to report issues
  12. --------------------
  13. Please report issues to
  14. `github issues <https://github.com/hyperledger/solang/issues>`_.
  15. Debugging issues with LLVM
  16. --------------------------
  17. The Solang compiler builds `LLVM IR <http://releases.llvm.org/8.0.1/docs/LangRef.html>`_.
  18. This is done via the `inkwell <https://github.com/TheDan64/inkwell>`_ crate, which is
  19. a "safe" rust wrapper. However, it is easy to construct IR which is invalid. When this
  20. happens you might get segfaults deep in llvm. There are two ways to help when this
  21. happens.
  22. Build LLVM with Assertions Enabled
  23. __________________________________
  24. If you are using llvm provided by your distribution, llvm will not be build with
  25. ``LLVM_ENABLE_ASSERTIONS=On``. See :ref:`llvm-from-source` how to build
  26. your own.
  27. Verify the IR with llc
  28. ______________________
  29. Some issues with the IR will not be detected even with LLVM Assertions on. These includes
  30. issues like instructions in a basic block after a branch instruction (i.e. unreachable
  31. instructions).
  32. Run ``solang --emit llvm -v foo.sol`` and you will get a foo.ll file, assuming that the
  33. contract in foo.sol is called foo. Try to compile this with ``llc foo.ll``. If IR is
  34. not valid, llc will tell you.
  35. Style guide
  36. -----------
  37. Solang follows default rustfmt, and clippy. Any clippy warnings need to be fixed.
  38. Outside of the tests, code should ideally be written in a such a way that no
  39. ``#[allow(clippy::foo)]`` are needed.
  40. For test code, this is much less strict. It is much more important that tests are
  41. written, and that they have good coverage rather than worrying about clippy warnings.
  42. Feel free to sprinkle some ``#[allow(clippy::foo)]`` around your test code to make
  43. your merge request pass.