summaryrefslogtreecommitdiffstats
path: root/libcxx/docs
diff options
context:
space:
mode:
authorLouis Dionne <ldionne@apple.com>2018-07-25 13:40:49 +0000
committerLouis Dionne <ldionne@apple.com>2018-07-25 13:40:49 +0000
commitf636411a5e1b8d1fe335cdc581bd41d2fb1280e3 (patch)
treed0dbace603e242282323f9c3a9b7a2d284a293b6 /libcxx/docs
parentb4e17c29dde38d8c9052c0d68110f5dfbf5323f2 (diff)
downloadbcm5719-llvm-f636411a5e1b8d1fe335cdc581bd41d2fb1280e3.tar.gz
bcm5719-llvm-f636411a5e1b8d1fe335cdc581bd41d2fb1280e3.zip
[NFC] Fix grammatical mistakes in libc++ FileTimeType design docs
llvm-svn: 337925
Diffstat (limited to 'libcxx/docs')
-rw-r--r--libcxx/docs/DesignDocs/FileTimeType.rst20
1 files changed, 10 insertions, 10 deletions
diff --git a/libcxx/docs/DesignDocs/FileTimeType.rst b/libcxx/docs/DesignDocs/FileTimeType.rst
index 4686e0aef72..488ff174b34 100644
--- a/libcxx/docs/DesignDocs/FileTimeType.rst
+++ b/libcxx/docs/DesignDocs/FileTimeType.rst
@@ -61,7 +61,7 @@ of representing the range of the ``timespec`` struct?
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 @@ Source Code Portability Across Implementations
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 @@ code in some way:
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 @@ what the underlying system uses, and because it might allow us to match
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 @@ directly. A ``chrono::duration`` represents its value as a tick period and a
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 @@ described by this paper.
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 @@ The Potential Solutions
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``.
OpenPOWER on IntegriCloud