Polishing documentation of libc++

libcxx/docs/CodingGuidelines.rst

@@ -79,9 +79,9 @@ and then check for ``#if _LIBCPP_SOMETHING_ENABLED`` instead of
 
 and then checking for ``#ifdef _LIBCPP_SOMETHING_ENABLED``.
 
-This makes it significantly easier to catch missing includes, since Clang and GCC will warn when using and undefined
-marco inside an ``#if`` statement when using ``-Wundef``. Some macros in libc++ don't use this style yet, so this only
-applies when introducing a new macro.
+This makes it significantly easier to catch missing includes: Clang and GCC with ``-Wundef`` enabled will warn
+when using an undefined macro inside an ``#if`` statement. Some macros in libc++ don't use this style yet,
+so this guideline only applies when introducing a new macro.
 
 This is partially enforced by the clang-tidy check ``libcpp-internal-ftms``.
 
@@ -107,9 +107,9 @@ This is enforced by the clang-tidy check ``libcpp-uglify-attributes``.
 Use C++11 extensions in C++03 code if they simplify the code
 ============================================================
 
-libc++ only supports Clang in C++98/03 mode. Clang provides many C++11 features in C++03, making it possible to write a
-lot of code in a simpler way than if we were restricted to C++03 features. Some use of extensions is even mandatory,
-since libc++ supports move semantics in C++03.
+libc++ supports the C++98/03 mode only with the Clang compiler. Clang provides many C++11 features
+in C++03, making it possible to write a lot of code in a simpler way than if we were restricted to C++03 features.
+Some use of extensions is even mandatory, since libc++ supports move semantics in C++03.
 
 Use ``using`` aliases instead of ``typedef``
 ============================================

libcxx/docs/Hardening.rst

@@ -32,8 +32,8 @@ modes are:
   including heuristic checks that might have significant performance overhead as
   well as internal library assertions. This mode should be used in
   non-production environments (such as test suites, CI, or local development).
-  We don’t commit to a particular level of performance in this mode and it’s
-  *not* intended to be used in production.
+  We do not commit to a particular level of performance in this mode.
+  In particular, this mode is *not* intended to be used in production.
 
 .. note::
 
@@ -155,13 +155,13 @@ easier to reason about the high-level semantics of a hardening mode.
   in the library -- whatever the consequences are, they will happen in the user
   code.
 
-- ``pedantic`` -- checks preconditions that are imposed by the Standard, but
-  violating which happens to be benign in libc++.
+- ``pedantic`` -- checks preconditions that are imposed by the C++ standard,
+  but violating which happens to be benign in libc++.
 
 - ``semantic-requirement`` -- checks that the given argument satisfies the
-  semantic requirements imposed by the Standard. Typically, there is no simple
-  way to completely prove that a semantic requirement is satisfied; thus, this
-  would often be a heuristic check and it might be quite expensive.
+  semantic requirements imposed by the C++ standard. Typically, there is no
+  simple way to completely prove that a semantic requirement is satisfied;
+  thus, this would often be a heuristic check and it might be quite expensive.
 
 - ``internal`` -- checks that internal invariants of the library hold. These
   assertions don't depend on user input.
@@ -239,7 +239,7 @@ Mapping between the hardening modes and the assertion categories
 
 .. note::
 
-  The categories enabled by each mode are subject to change and users should not
+  The categories enabled by each mode are subject to change. Users should not
   rely on the precise assertions enabled by a mode at a given point in time.
   However, the library does guarantee to keep the hardening modes stable and
   to fulfill the semantics documented here.

libcxx/docs/ImplementationDefinedBehavior.rst

@@ -4,8 +4,8 @@
 Implementation-defined behavior
 ===============================
 
-Contains the implementation details of the implementation-defined behavior in
-libc++. Implementation-defined is mandated to be documented by the Standard.
+This document contains the implementation details of the implementation-defined behavior in libc++.
+The C++ standard mandates that implementation-defined behavior is documented.
 
 .. note:
    This page is far from complete.
@@ -17,7 +17,7 @@ Implementation-defined behavior
 Updating the Time Zone Database
 -------------------------------
 
-The Standard allows implementations to automatically update the
+The C++ standard allows implementations to automatically update the
 *remote time zone database*. Libc++ opts not to do that. Instead calling
 
  - ``std::chrono::remote_version()`` will update the version information of the
@@ -32,7 +32,7 @@ give them full control over the process.
 `[ostream.formatted.print]/3 <http://eel.is/c++draft/ostream.formatted.print#3>`_ A terminal capable of displaying Unicode
 --------------------------------------------------------------------------------------------------------------------------
 
-The Standard specifies that the manner in which a stream is determined to refer
+The C++ standard specifies that the manner in which a stream is determined to refer
 to a terminal capable of displaying Unicode is implementation-defined. This is
 used for ``std::print`` and similar functions taking an ``ostream&`` argument.
 
@@ -55,9 +55,9 @@ Libc++ determines that a stream is Unicode-capable terminal by:
 ----------------------------------------------------------------------------------------
 
 Most functions within the Mathematical Special Functions section contain integral indices.
-The Standard specifies the result for larger indices as implementation-defined.
+The C++ standard specifies the result for larger indices as implementation-defined.
 Libc++ pursuits reasonable results by choosing the same formulas as for indices below that threshold.
-E.g.
+E.g.,
 
 - ``std::hermite(unsigned n, T x)`` for ``n >= 128``
 

libcxx/docs/Modules.rst

@@ -24,7 +24,7 @@ Overview
 
 The module sources are stored in ``.cppm`` files. Modules need to be available
 as BMIs, which are ``.pcm`` files for Clang. BMIs are not portable, they depend
-on the compiler used and its compilation flags. Therefore there needs to be a
+on the compiler and the compilation flags used. Therefore there needs to be a
 way to distribute the ``.cppm`` files to the user and offer a way for them to
 build and use the ``.pcm`` files. It is expected this will be done by build
 systems in the future. To aid early adaptor and build system vendors libc++