brintos

brintos / llvm-project-archived public Read only

0
0
Text · 2.8 KiB · a674290 Raw
53 lines · plain
1.. _contributing:2 3================================4Contributing to the libc Project5================================6 7LLVM-libc is being developed as part of the LLVM project so contributions8to the libc project should also follow the general LLVM9`contribution guidelines <https://llvm.org/docs/Contributing.html>`_. Below is10a list of open projects that one can start with:11 12#. **Beginner Bugs** - Help us tackle13   `good first issues <https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+label%3Alibc+label%3A%22good+first+issue%22>`__.14   These bugs have been tagged with the github labels "libc" and "good first15   issue" by the team as potentially easier places to get started.  Please do16   first check if the bug has an assignee; if so please find another unless17   there's been no movement on the issue from the assignee, in which place do18   ask if you can help take over.19 20#. **Cleanup code-style** - The libc project follows the general21   `LLVM style <https://llvm.org/docs/CodingStandards.html>`_ but differs in a22   few aspects: We use ``snake_case`` for non-constant variable and function23   names,``CamelCase`` for internal type names (those which are not defined in a24   public header), and ``CAPITALIZED_SNAKE_CASE`` for constants. When we started25   working on the project, we started using the general LLVM style for26   everything. However, for a short period, we switched to the style that is27   currently followed by the `LLD project <https://github.com/llvm/llvm-project/tree/main/lld>`_.28   But, considering that we implement a lot of functions and types whose names29   are prescribed by the standards, we have settled on the style described above.30   However, we have not switched over to this style in all parts of the ``libc``31   directory. So, a simple but mechanical project would be to move the parts32   following the old styles to the new style.33 34#. **Implement Linux syscall wrappers** - A large portion of the POSIX API can35   be implemented as syscall wrappers on Linux. A good number have already been36   implemented but many more are yet to be implemented. So, a project of medium37   complexity would be to implement syscall wrappers which have not yet been38   implemented.39 40#. **Update the clang-tidy lint rules and use them in the build and/or CI** -41   Currently, the :ref:`clang_tidy_checks` have gone stale and are mostly unused42   by the developers and on the CI builders. This project is about updating43   them and reintegrating them back with the build and running them on the44   CI builders.45 46#. **double and higher precision math functions** - These are under active47   development but you can take a shot at those not yet implemented. See48   :ref:`math` for more information.49 50#. **Contribute a new OS/Architecture port** - You can contribute a new51   operating system or target architecture port. See :ref:`porting` for more52   information.53