Skip to content

[libc++] Fix typos in documentation #139853

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 15, 2025

Conversation

kazutakahirata
Copy link
Contributor

No description provided.

@kazutakahirata kazutakahirata requested a review from a team as a code owner May 14, 2025 06:51
@llvmbot llvmbot added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label May 14, 2025
@llvmbot
Copy link
Member

llvmbot commented May 14, 2025

@llvm/pr-subscribers-libcxx

Author: Kazu Hirata (kazutakahirata)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/139853.diff

3 Files Affected:

  • (modified) libcxx/docs/CodingGuidelines.rst (+1-1)
  • (modified) libcxx/docs/DesignDocs/FileTimeType.rst (+8-8)
  • (modified) libcxx/docs/TestingLibcxx.rst (+2-2)
diff --git a/libcxx/docs/CodingGuidelines.rst b/libcxx/docs/CodingGuidelines.rst
index 4a601dffa87ca..5e24807a71fb0 100644
--- a/libcxx/docs/CodingGuidelines.rst
+++ b/libcxx/docs/CodingGuidelines.rst
@@ -124,7 +124,7 @@ 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
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);

@ldionne ldionne changed the title [libcxx] Fix typos in documentation [libc++] Fix typos in documentation May 15, 2025
@ldionne ldionne merged commit b7d6a54 into llvm:main May 15, 2025
85 checks passed
TIFitis pushed a commit to TIFitis/llvm-project that referenced this pull request May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants