[libcxx-commits] [libcxx] b7d6a54 - [libc++] Fix typos in documentation (#139853)

[via libcxx-commits]

Author: Kazu Hirata
Date: 2025-05-15T10:35:32-04:00
New Revision: b7d6a54703823bfba2b437e4b764ceb16b73c2af

URL: https://github.com/llvm/llvm-project/commit/b7d6a54703823bfba2b437e4b764ceb16b73c2af
DIFF: https://github.com/llvm/llvm-project/commit/b7d6a54703823bfba2b437e4b764ceb16b73c2af.diff

LOG: [libc++] Fix typos in documentation (#139853)

Added: 
    

Modified: 
    libcxx/docs/CodingGuidelines.rst
    libcxx/docs/DesignDocs/FileTimeType.rst
    libcxx/docs/TestingLibcxx.rst

Removed: 
    


################################################################################
diff  --git a/libcxx/docs/CodingGuidelines.rst b/libcxx/docs/CodingGuidelines.rst
index 4a601dffa87ca..ff312d16cf7bb 100644
--- a/libcxx/docs/CodingGuidelines.rst
+++ b/libcxx/docs/CodingGuidelines.rst
@@ -124,8 +124,8 @@ Write SFINAE with ``requires`` clauses in C++20-only code
 subsume other concepts. This means that overloads based on traits can be written without negating more general cases.
 They also show intent better.
 
-Write ``enable_if`` as ``enable_if_t<conditon, int> = 0``
-=========================================================
+Write ``enable_if`` as ``enable_if_t<condition, int> = 0``
+==========================================================
 
 The form ``enable_if_t<condition, int> = 0`` is the only one that works in every language mode and for overload sets
 using the same template arguments otherwise. If the code must work in C++11 or C++03, the libc++-internal alias

diff  --git a/libcxx/docs/DesignDocs/FileTimeType.rst b/libcxx/docs/DesignDocs/FileTimeType.rst
index f775fd840e236..946c9e515fb9b 100644
--- a/libcxx/docs/DesignDocs/FileTimeType.rst
+++ b/libcxx/docs/DesignDocs/FileTimeType.rst
@@ -33,7 +33,7 @@ which is defined as follows:
   };
 
 To represent the range and resolution of ``timespec``, we need to (A) have
-nanosecond resolution, and (B) use more than 64 bits (assuming a 64 bit ``time_t``).
+nanosecond resolution, and (B) use more than 64 bits (assuming a 64-bit ``time_t``).
 
 As the standard requires us to use the ``chrono`` interface, we have to define
 our own filesystem clock which specifies the period and representation of
@@ -207,7 +207,7 @@ code in some way:
 
   // Overflow during creation bug.
   file_time_type timespec_to_file_time_type(struct timespec ts) {
-    // woops! chrono::seconds and chrono::nanoseconds use a 64 bit representation
+    // woops! chrono::seconds and chrono::nanoseconds use a 64-bit representation
     // this may overflow before it's converted to a file_time_type.
     auto dur = seconds(ts.tv_sec) + nanoseconds(ts.tv_nsec);
     return file_time_type(dur);
@@ -272,7 +272,7 @@ look like.
 
 The first thing to notice is that we can't construct ``fs_timespec_rep`` like
 a ``timespec`` by passing ``{secs, nsecs}``. Instead we're limited to
-constructing it from a single 64 bit integer.
+constructing it from a single 64-bit integer.
 
 We also can't allow the user to inspect the ``tv_sec`` or ``tv_nsec`` values
 directly. A ``chrono::duration`` represents its value as a tick period and a
@@ -350,12 +350,12 @@ Though the above example may appear silly, I think it follows from the incorrect
 notion that using a ``timespec`` rep in chrono actually makes it act as if it
 were an actual ``timespec``.
 
-Interactions with 32 bit ``time_t``
+Interactions with 32-bit ``time_t``
 -----------------------------------
 
 Up until now we've only be considering cases where ``time_t`` is 64 bits, but what
-about 32 bit systems/builds where ``time_t`` is 32 bits? (this is the common case
-for 32 bit builds).
+about 32-bit systems/builds where ``time_t`` is 32 bits? (this is the common case
+for 32-bit builds).
 
 When ``time_t`` is 32 bits, we can implement ``file_time_type`` simply using 64-bit
 ``long long``. There is no need to get either ``__int128_t`` or ``timespec`` emulation
@@ -431,11 +431,11 @@ Pros:
 
 Cons:
 
-* It isn't always available (but on 64 bit machines, it normally is).
+* It isn't always available (but on 64-bit machines, it normally is).
 * It causes ``file_time_type`` to have a larger range than ``timespec``.
 * It doesn't always act the same as other builtin integer types. For example
   with ``cout`` or ``to_string``.
-* Allows implicit truncation to 64 bit integers.
+* Allows implicit truncation to 64-bit integers.
 * It can be implicitly converted to a builtin integer type by the user,
   truncating its value.
 

diff  --git a/libcxx/docs/TestingLibcxx.rst b/libcxx/docs/TestingLibcxx.rst
index 9c2ac9edb6777..3320f7d2e7691 100644
--- a/libcxx/docs/TestingLibcxx.rst
+++ b/libcxx/docs/TestingLibcxx.rst
@@ -291,7 +291,7 @@ tests using exceptions. The code to write a test manually would be:
 
 .. code-block:: cpp
 
-  void test_excption([[maybe_unused]] int arg) {
+  void test_exception([[maybe_unused]] int arg) {
   #ifndef TEST_HAS_NO_EXCEPTIONS // do nothing when tests are disabled
     try {
       foo(arg);
@@ -308,7 +308,7 @@ The same test using a macro:
 
 .. code-block:: cpp
 
-  void test_excption([[maybe_unused]] int arg) {
+  void test_exception([[maybe_unused]] int arg) {
     TEST_VALIDATE_EXCEPTION(bar,
                             [](const bar& e) {
                               LIBCPP_ASSERT(e.what() == what);