[libc-commits] [libc] e042efd - [libc] Fix typos in documentation
Kazu Hirata via libc-commits
libc-commits at lists.llvm.org
Mon Apr 24 23:31:59 PDT 2023
Author: Kazu Hirata
Date: 2023-04-24T23:31:48-07:00
New Revision: e042efdab69b2139882e8a31cb871dee5dc4638e
URL: https://github.com/llvm/llvm-project/commit/e042efdab69b2139882e8a31cb871dee5dc4638e
DIFF: https://github.com/llvm/llvm-project/commit/e042efdab69b2139882e8a31cb871dee5dc4638e.diff
LOG: [libc] Fix typos in documentation
Added:
Modified:
libc/docs/contributing.rst
libc/docs/dev/api_test.rst
libc/docs/dev/code_style.rst
libc/docs/dev/mechanics_of_public_api.rst
libc/docs/math/log.rst
libc/docs/overlay_mode.rst
libc/docs/porting.rst
Removed:
################################################################################
diff --git a/libc/docs/contributing.rst b/libc/docs/contributing.rst
index 65ba9a4079704..7f02630145eb9 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 e39d506c3a92f..85239bbe78941 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 e29ebf99d03e2..edbd0ef75438c 100644
--- a/libc/docs/dev/code_style.rst
+++ b/libc/docs/dev/code_style.rst
@@ -15,11 +15,11 @@
diff erences 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 992c8ac304a6f..257ab3d71bc17 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 c8095556cc2ac..83d03a83d131e 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 723ec5bb2522d..f9b566658bb49 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 42f7fa33bc334..3f41eb2c96991 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 <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>`_
More information about the libc-commits
mailing list