[libc] Fix typos in documentation

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.

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.

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.

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

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:
 

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:

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 <https://github.com/llvm/llvm-project/tree/main/libc/config/linux/aarch64>`_
 config and the
 `x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/linux/x86_64>`_