Merge #234: doc: Fix typos and grammar in documentation and comments

458745e Fix various typos, spelling mistakes, and grammatical errors in design.md and source code comments. (Ehnamuram Enoch)

Pull request description:

  This PR fixes various typos, spelling mistakes, and grammatical errors found in `doc/design.md` and source code comments to improve readability.

ACKs for top commit:
  maflcko:
    lgtm ACK 458745e
  ryanofsky:
    Code review ACK 458745e. Thanks for the fixes!

Tree-SHA512: 61f4de5369aef2f2c963c95a3d898a70c7c7a2bbe1a17ae2ac47d89e5436ad16b68cf2e7849da1a6701fd247509eba2dfef0e4db32d5583ebe8d735ae347049a

Author: ryanofsky

doc/design.md

@@ -199,7 +199,7 @@ If this is the first asynchronous request made from the current client thread, `
 3. Create a local `Thread::Server` object for the current thread (stored in `callback_threads` map)
 4. Set the local thread capability in `Context.callbackThread`
 
-Subsequent requests will resuse the existing thread capabilites held in `callback_threads` and `request_threads`.
+Subsequent requests will reuse the existing thread capabilities held in `callback_threads` and `request_threads`.
 
 **Server side** (`PassField`):
 1. Looks up the local `Thread::Server` object specified by `context.thread`

include/mp/proxy-io.h

@@ -317,12 +317,12 @@ class EventLoop
     void* m_context;
 };
 
-//! Single element task queue used to handle recursive capnp calls. (If server
-//! makes an callback into the client in the middle of a request, while client
+//! Single element task queue used to handle recursive capnp calls. (If the
+//! server makes a callback into the client in the middle of a request, while the client
 //! thread is blocked waiting for server response, this is what allows the
-//! client to run the request in the same thread, the same way code would run in
-//! single process, with the callback sharing same thread stack as the original
-//! call.
+//! client to run the request in the same thread, the same way code would run in a
+//! single process, with the callback sharing the same thread stack as the original
+//! call.)
 struct Waiter
 {
     Waiter() = default;

include/mp/proxy-types.h

@@ -87,7 +87,7 @@ struct StructField
 // actually construct the read destination object. For example, if a std::string
 // is being read, the ReadField call will call the custom emplace_fn with char*
 // and size_t arguments, and the emplace function can decide whether to call the
-// constructor via the operator or make_shared or emplace or just return a
+// constructor via the operator, make_shared, emplace or just return a
 // temporary string that is moved from.
 template <typename LocalType, typename EmplaceFn>
 struct ReadDestEmplace
@@ -205,11 +205,11 @@ void BuildField(TypeList<LocalTypes...>, Context& context, Output&& output, Valu
     }
 }
 
-// Adapter to let BuildField overloads methods work set & init list elements as
-// if they were fields of a struct. If BuildField is changed to use some kind of
-// accessor class instead of calling method pointers, then then maybe this could
-// go away or be simplified, because would no longer be a need to return
-// ListOutput method pointers emulating capnp struct method pointers..
+// Adapter that allows BuildField overloads to work with, set, and initialize list
+// elements as if they were fields of a struct. If BuildField is changed to use some
+// kind of accessor class instead of calling method pointers, then maybe this could
+// go away or be simplified, because there would no longer be a need to return
+// ListOutput method pointers emulating capnp struct method pointers.
 template <typename ListType>
 struct ListOutput;
 

src/mp/gen.cpp

@@ -136,7 +136,7 @@ static bool BoxedType(const ::capnp::Type& type)
 // include_prefix can be used to control relative include paths used in
 // generated files. For example if src_file is "/a/b/c/d/file.canp" and
 // include_prefix is "/a/b/c" include lines like
-// "#include <d/file.capnp.proxy.h>" "#include <d/file.capnp.proxy-types.h>"i
+// "#include <d/file.capnp.proxy.h>", "#include <d/file.capnp.proxy-types.h>"
 // will be generated.
 static void Generate(kj::StringPtr src_prefix,
     kj::StringPtr include_prefix,

src/mp/proxy.cpp

@@ -102,12 +102,12 @@ Connection::~Connection()
     // The ProxyClient cleanup handlers are synchronous because they are fast
     // and don't do anything besides release capnp resources and reset state so
     // future calls to client methods immediately throw exceptions instead of
-    // trying to communicating across the socket. The synchronous callbacks set
+    // trying to communicate across the socket. The synchronous callbacks set
     // ProxyClient capability pointers to null, so new method calls on client
     // objects fail without triggering i/o or relying on event loop which may go
     // out of scope or trigger obscure capnp i/o errors.
     //
-    // The ProxySever cleanup handlers call user defined destructors on server
+    // The ProxyServer cleanup handlers call user defined destructors on the server
     // object, which can run arbitrary blocking bitcoin code so they have to run
     // asynchronously in a different thread. The asynchronous cleanup functions
     // intentionally aren't started until after the synchronous cleanup
@@ -136,7 +136,7 @@ Connection::~Connection()
     //
     // Either way disconnect code runs in the event loop thread and called both
     // on clean and unclean shutdowns. In unclean shutdown case when the
-    // connection is broken, sync and async cleanup lists will filled with
+    // connection is broken, sync and async cleanup lists will be filled with
     // callbacks. In the clean shutdown case both lists will be empty.
     Lock lock{m_loop->m_mutex};
     while (!m_sync_cleanup_fns.empty()) {