[NFC] Fix grammatical mistakes in libc++ FileTimeType design docs
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337925 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/docs/DesignDocs/FileTimeType.rst b/docs/DesignDocs/FileTimeType.rst
index 4686e0a..488ff17 100644
--- a/docs/DesignDocs/FileTimeType.rst
+++ b/docs/DesignDocs/FileTimeType.rst
@@ -61,7 +61,7 @@
Problems To Consider
====================
-Before considering solutions, lets consider the problems they should solve,
+Before considering solutions, let's consider the problems they should solve,
and how important solving those problems are:
@@ -187,7 +187,7 @@
As we've discussed, ``file_time_type`` needs a representation that uses more
than 64 bits. The possible solutions include using ``__int128_t``, emulating a
128 bit integer using a class, or potentially defining a ``timespec`` like
-arithmetic type. All three will solve allow us to, at minimum, match the range
+arithmetic type. All three will allow us to, at minimum, match the range
and resolution, and the last one might even allow us to match them exactly.
But when considering these potential solutions we need to consider more than
@@ -214,7 +214,7 @@
file_time_type correct_timespec_to_file_time_type(struct timespec ts) {
// This is the correct version of the above example, where we
- // avoid using the chrono typedefs as their not sufficient.
+ // avoid using the chrono typedefs as they're not sufficient.
// Can we expect users to avoid this bug?
using fs_seconds = chrono::duration<file_time_type::rep>;
using fs_nanoseconds = chrono::duration<file_time_type::rep, nano>;
@@ -252,7 +252,7 @@
the range and resolution exactly. But would it work with chrono? And could
it still act at all like a ``timespec`` struct?
-For ease of consideration, lets consider the what the implementation might
+For ease of consideration, let's consider what the implementation might
look like.
.. code-block:: cpp
@@ -278,11 +278,11 @@
number of ticks stored using ``rep``. The representation is unaware of the
tick period it is being used to represent, but ``timespec`` is setup to assume
a nanosecond tick period; which is the only case where the names ``tv_sec``
-and ``tv_nsec`` matche the values they store.
+and ``tv_nsec`` match the values they store.
-When we convert a nanosecond duration to a seconds, ``fs_timespec_rep`` will
+When we convert a nanosecond duration to seconds, ``fs_timespec_rep`` will
use ``tv_sec`` to represent the number of giga seconds, and ``tv_nsec`` the
-remaining seconds. Lets consider how this might cause a bug were users allowed
+remaining seconds. Let's consider how this might cause a bug were users allowed
to manipulate the fields directly.
.. code-block:: cpp
@@ -364,8 +364,8 @@
Obviously our implementation for 32-bit builds should act as similarly to the
64-bit build as possible. Code which compiles in one, should compile in the other.
This consideration is important when choosing between ``__int128_t`` and
-emulating ``timespec``. The solution which provides the most uniformity is
-the preferable one, with the least eccentricity is the preferable one.
+emulating ``timespec``. The solution which provides the most uniformity with
+the least eccentricity is the preferable one.
Summary
=======
@@ -391,7 +391,7 @@
Pros:
-* As a type ``long long`` places the nicest with others:
+* As a type ``long long`` plays the nicest with others:
* It works with streaming operators and other library entities which support
builtin integer types, but don't support ``__int128_t``.