contributing.rst 3.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
  1. Contributing
  2. ============
  3. Solang is in active development, so there are many ways in which you can
  4. contribute.
  5. * Consider that users who will read the docs are from different background and cultures and that they have different preferences.
  6. * Avoid potential offensive terms and, for instance, prefer "allow list and deny list" to "white list and black list".
  7. * 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.
  8. * We suggest to refer to `Microsoft bias free writing guidelines <https://docs.microsoft.com/en-us/style-guide/bias-free-communication>`_
  9. and `Google inclusive doc writing guide <https://developers.google.com/style/inclusive-documentation>`_ as starting points.
  10. How to report issues
  11. --------------------
  12. Please report issues to
  13. `github issues <https://github.com/hyperledger-solang/solang/issues>`_.
  14. How to contribute code
  15. ----------------------
  16. Code contributions are submitted via
  17. `pull requests <https://github.com/hyperledger-solang/solang/compare>`_.
  18. Please fork this repository and make desired changes inside a dedicated branch on your fork.
  19. Prior to opening a pull request for your branch, make sure that the code in your branch
  20. * does compile without any warnings (run ``cargo build --workspace``)
  21. * does not produce any clippy lints (run ``cargo clippy --workspace``)
  22. * does pass all unit tests (run ``cargo test --workspace``)
  23. * has no merge conflicts with the ``main`` branch
  24. * is correctly formatted (run ``cargo fmt --all`` if your IDE does not do that automatically)
  25. Target Specific
  26. ---------------
  27. Solang supports Polkadot and Solana. These targets need testing
  28. via integration tests. New targets like
  29. `Fabric <https://github.com/hyperledger-solang/fabric-chaincode-wasm>`_ need to be
  30. added, and tests added.
  31. Debugging issues with LLVM
  32. --------------------------
  33. The Solang compiler builds `LLVM IR <http://releases.llvm.org/8.0.1/docs/LangRef.html>`_.
  34. This is done via the `inkwell <https://github.com/TheDan64/inkwell>`_ crate, which is
  35. a "safe" rust wrapper. However, it is easy to construct IR which is invalid. When this
  36. happens you might get segfaults deep in llvm. There are two ways to help when this
  37. happens.
  38. Build LLVM with Assertions Enabled
  39. __________________________________
  40. If you are using llvm provided by your distribution, llvm will not be build with
  41. ``LLVM_ENABLE_ASSERTIONS=On``. See :ref:`llvm-from-source` how to build
  42. your own.
  43. Verify the IR with llc
  44. ______________________
  45. Some issues with the IR will not be detected even with LLVM Assertions on. These includes
  46. issues like instructions in a basic block after a branch instruction (i.e. unreachable
  47. instructions).
  48. Run ``solang --emit llvm -v foo.sol`` and you will get a foo.ll file, assuming that the
  49. contract in foo.sol is called foo. Try to compile this with ``llc foo.ll``. If IR is
  50. not valid, llc will tell you.
  51. Style guide
  52. -----------
  53. Solang follows default rustfmt, and clippy. Any clippy warnings need to be fixed.
  54. Outside of the tests, code should ideally be written in a such a way that no
  55. ``#[allow(clippy::foo)]`` are needed.
  56. For test code, this is much less strict. It is much more important that tests are
  57. written, and that they have good coverage rather than worrying about clippy warnings.
  58. Feel free to sprinkle some ``#[allow(clippy::foo)]`` around your test code to make
  59. your merge request pass.