+.. _api_test:
+
+========
API Test
-=====================
+========
The implementation of libc-project is unique because our public C header files
are generated using information from ground truth captured in TableGen files.
Unit tests only exercise the internal C++ implementations and don't ensure the
-.. _clangtidy_rules:
+.. _clang_tidy_checks:
LLVM libc clang-tidy checks
===========================
-LLVM libc build rules
-=====================
+.. _cmake_build_rules:
+
+===========================
+The libc CMake build system
+===========================
At the cost of verbosity, we want to keep the build system of LLVM libc
as simple as possible. We also want to be highly modular with our build
--- /dev/null
+.. _code_style:
+
+===================
+The libc code style
+===================
+
+For the large part, the libc project follows the general `coding standards of
+the LLVM project <https://llvm.org/docs/CodingStandards.html>`_. The libc
+project differs from that standard with respect to the naming style. The
+differences are as follows:
+
+#. **Non-const variables** - This includes function arguments, struct and
+ class data members, non-const globals and local variables. They all use the
+ ``snake_case`` style.
+#. **const and constexpr variables** - They use the capitlized
+ ``SNAKE_CASE`` irrespective of whether they are local or global.
+#. **Function and methods** - They use the ``snake_case`` style like the
+ non-const variables.
+#. **Internal type names** - These are types which are interal to the libc
+ implementation. They use the `CaptilizedCamelCase` style.
+#. **Public names** - These are the names as prescribed by the standards and
+ will follow the style as prescribed by the standards.
to a fast random number generator with a large range.
#. **Update the clang-tidy lint rules and use them in the build and/or CI** -
- Currently, the :ref:`clangtidy_rules` have gone stale and are mostly unused
+ Currently, the :ref:`clang_tidy_checks` have gone stale and are mostly unused
by the developers and on the CI builders. This project is about updating
them and reintegrating them back with the build and running them on the
CI builders.
--- /dev/null
+.. _developer_guides:
+
+================
+Developer Guides
+================
+
+Navigate to the links below for information on the respective topics:
+
+.. toctree::
+
+ code_style
+ source_tree_layout
+ entrypoints
+ cmake_build_rules
+ clang_tidy_checks
+ fuzzing
+ ground_truth_specification
+ header_generation
+ implementation_standard
+ api_test
+ mechanics_of_public_api
:maxdepth: 1
:caption: Development
- build_system
- clang_tidy_checks
- entrypoints
- fuzzing
- ground_truth_specification
- header_generation
- implementation_standard
- api_test
- mechanics_of_public_api
- source_layout
+ developer_guides
porting
contributing
$> ninja install-llvmlibc
-Building the static archive as part of the runtimes build
----------------------------------------------------------
+Building the static archive as part of the bootstrap build
+----------------------------------------------------------
-The runtimes build is a build mode in which runtime components like libc++,
+The bootstrap build is a build mode in which runtime components like libc++,
libcxx-abi, libc etc. are built using the ToT clang. The idea is that this build
produces an in-sync toolchain of compiler + runtime libraries. Such a synchrony
is not essential for the libc but can one still build the overlay static archive
-as part of the runtimes build if one wants to. The first step is to configure
+as part of the bootstrap build if one wants to. The first step is to configure
appropriately:
.. code-block:: sh
+.. _source_tree_layout:
+
+============================
LLVM-libc Source Tree Layout
============================