diff --git a/libc/docs/contributing.rst b/libc/docs/contributing.rst index 65ba9a407970..7f02630145eb 100644 --- a/libc/docs/contributing.rst +++ b/libc/docs/contributing.rst @@ -48,9 +48,9 @@ a list of open projects that one can start with: CI builders. #. **double and higher precision math functions** - These are under active - developement but you can take a shot at those not yet implemented. See + development but you can take a shot at those not yet implemented. See :ref:`math` for more information. #. **Contribute a new OS/Architecture port** - You can contribute a new operating system or target architecture port. See :ref:`porting` for more - informaton. + information. diff --git a/libc/docs/dev/api_test.rst b/libc/docs/dev/api_test.rst index e39d506c3a92..85239bbe7894 100644 --- a/libc/docs/dev/api_test.rst +++ b/libc/docs/dev/api_test.rst @@ -7,7 +7,7 @@ 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 headers were generated by the build system and that the generated header files -contain the extpected declarations and definitions. A simple solution is to have +contain the expected declarations and definitions. A simple solution is to have contributors write an integration test for each individual function as a C program; however, this would place a large burden on contributors and duplicates some effort from the unit tests. diff --git a/libc/docs/dev/code_style.rst b/libc/docs/dev/code_style.rst index e29ebf99d03e..edbd0ef75438 100644 --- a/libc/docs/dev/code_style.rst +++ b/libc/docs/dev/code_style.rst @@ -15,11 +15,11 @@ 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 +#. **const and constexpr variables** - They use the capitalized ``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 +#. **Internal type names** - These are types which are internal 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. @@ -39,7 +39,7 @@ We define two kinds of macros: **code defined** and **build defined** macros. * **Properties** - Build related properties like used compiler, target architecture or enabled CPU features defined by introspecting compiler - defined preprocessor defininitions. e.g., ``LIBC_TARGET_ARCH_IS_ARM``, + defined preprocessor definitions. e.g., ``LIBC_TARGET_ARCH_IS_ARM``, ``LIBC_TARGET_CPU_HAS_AVX2``, ``LIBC_COMPILER_IS_CLANG``, ... * **Attributes** - Compiler agnostic attributes or functions to handle specific operations. e.g., ``LIBC_INLINE``, ``LIBC_NO_LOOP_UNROLL``, @@ -98,7 +98,7 @@ followed: #. The header file ``src/errno/libc_errno.h`` is shipped as part of the target corresponding to the ``errno`` entrypoint ``libc.src.errno.errno``. We do - not in general allow dependecies between entrypoints. However, the ``errno`` + not in general allow dependencies between entrypoints. However, the ``errno`` entrypoint is the only exceptional entrypoint on which other entrypoints should explicitly depend on if they set ``errno`` to indicate error conditions. @@ -155,5 +155,5 @@ The only exception to using the above pattern is if allocating using the failures will still need to be handled gracefully. Further, keep in mind that these functions do not call the constructors and destructors of the allocated/deallocated objects. So, use these functions carefully and only -when it is absolutely clear that constructor and desctructor invocation is +when it is absolutely clear that constructor and destructor invocation is not required. diff --git a/libc/docs/dev/mechanics_of_public_api.rst b/libc/docs/dev/mechanics_of_public_api.rst index 992c8ac304a6..257ab3d71bc1 100644 --- a/libc/docs/dev/mechanics_of_public_api.rst +++ b/libc/docs/dev/mechanics_of_public_api.rst @@ -17,7 +17,7 @@ The API config file lists two kinds of items: 1. The list of standards from which the public entities available on the platform are derived from. -2. For each header file exposed on the platfrom, the list of public members +2. For each header file exposed on the platform, the list of public members provided in that header file. Note that, the header generator only learns the names of the public entities diff --git a/libc/docs/math/log.rst b/libc/docs/math/log.rst index c8095556cc2a..83d03a83d131 100644 --- a/libc/docs/math/log.rst +++ b/libc/docs/math/log.rst @@ -70,7 +70,7 @@ d. add step a and step c results. How to derive `r` ----------------- -For an efficient implementation, we would like to use the first `M` signficicant +For an efficient implementation, we would like to use the first `M` significant bits of `m_x` to look up for `r`. In particular, we would like to find a value of `r` that works for all `m_x` satisfying: diff --git a/libc/docs/overlay_mode.rst b/libc/docs/overlay_mode.rst index 723ec5bb2522..f9b566658bb4 100644 --- a/libc/docs/overlay_mode.rst +++ b/libc/docs/overlay_mode.rst @@ -109,7 +109,7 @@ Linking the static archive to other LLVM binaries Since the libc and other LLVM binaries are developed in the same source tree, linking ``libllvmlibc.a`` to those LLVM binaries does not require any special -install step or explicity passing any special linker flags/options. One can +install step or explicitly passing any special linker flags/options. One can simply add ``llvmlibc`` as a link library to that binary's target. For example, if you want to link ``libllvmlibc.a`` to ``llvm-objcopy``, all you have to do is to add a CMake command as follows: diff --git a/libc/docs/porting.rst b/libc/docs/porting.rst index 42f7fa33bc33..3f41eb2c9699 100644 --- a/libc/docs/porting.rst +++ b/libc/docs/porting.rst @@ -107,13 +107,13 @@ updated. The headers.txt file ==================== -Another important piece of config informtion is listed in a file named +Another important piece of config information is listed in a file named ``headers.txt``. It lists the targets for the set of public headers that are provided by the libc. This is relevant only if the libc is to be used in the :ref:`fullbuild_mode` on the target operating system and architecture. As with the ``entrypoints.txt`` file, one ``headers.txt`` file should be listed for each individual target architecture if you are doing an architecture specific -bring up. The Linux config has ``headers.txt`` file listed seperately for the +bring up. The Linux config has ``headers.txt`` file listed separately for the `aarch64 `_ config and the `x86_64 `_