diff --git a/docs/build_system.md b/docs/build_system.md index 6204e4e84f75f..4a3408d80b833 100644 --- a/docs/build_system.md +++ b/docs/build_system.md @@ -174,7 +174,7 @@ using. #### Adding tests to a suite #### Running individual tests -## Modifying the buid system +## Modifying the build system ### What is SCons? #### `SConstruct` and `SConscripts` #### `Environments `and their `Clone`s diff --git a/docs/evergreen-testing/configuration.md b/docs/evergreen-testing/configuration.md index 0aa811bdc2e39..520fd46e41d86 100644 --- a/docs/evergreen-testing/configuration.md +++ b/docs/evergreen-testing/configuration.md @@ -13,7 +13,7 @@ section of the Evergreen wiki. ### `mongodb-mongo-master` The main project for testing MongoDB's dev environments with a number build variants, each one corresponding to a particular compile or testing environment to support development. -Each build variant runs a set of tasks; each task ususally runs one or more tests. +Each build variant runs a set of tasks; each task usually runs one or more tests. ### `mongodb-mongo-master-nightly Tracks the same branch as `mongodb-mongo-master`, each build variant corresponds to a diff --git a/docs/futures_and_promises.md b/docs/futures_and_promises.md index 550f05dff54d0..4b65f699eab5d 100644 --- a/docs/futures_and_promises.md +++ b/docs/futures_and_promises.md @@ -88,7 +88,7 @@ a high level, but we've left out some important details about how they work. ### How Are Futures Fulfilled With Values? In our example, we looked at how some code that needs to wait for results can use `Future`s to be written in an asynchronous, performant way. But some thread running elsewhere needs to actually -"fulfill" those futures with a value or error. Threads can fulfull the core "promise" of a +"fulfill" those futures with a value or error. Threads can fulfill the core "promise" of a `Future<T>` - that it will eventually contain a `T` or an error - by using the appropriately named `Promise<T>` type. Every pending `Future<T>` is associated with exactly one corresponding `Promise<T>` that can be used to ready the `Future<T>`, providing it with a value. (Note that a @@ -266,7 +266,7 @@ continuation-chaining member functions in [future.h][future], starting above the At some point, we may have no more continuations to add to a future chain, and will want to either synchronously extract the value or error held in the last future of the chain, or add a callback to asynchronously consume this value. The `.get()` and `.getAsync()` members of future-like types -provide these facilities for terminating a future chain by extracting or asynchronouslyunsly +provide these facilities for terminating a future chain by extracting or asynchronously consuming the result of the chain. The `.getAsync()` function works much like `.onCompletion()`, taking a `Status` or `StatusWith<T>` and running regardless of whether or not the previous link in the chain resolved with error or success, and running asynchronously when the previous results are diff --git a/docs/golden_data_test_framework.md b/docs/golden_data_test_framework.md index 1187c5aa5fcb0..2ab69dc4898a2 100644 --- a/docs/golden_data_test_framework.md +++ b/docs/golden_data_test_framework.md @@ -61,8 +61,8 @@ be included in the diff. * When resolving merge conflicts on the expected output files, one of the approaches below SHOULD be used: * "Accept theirs", rerun the tests and verify new outputs. This doesn't require knowledge of - production/test code changes in "theirs" branch, but requires re-review and re-acceptance of c - hanges done by local branch. + production/test code changes in "theirs" branch, but requires re-review and re-acceptance of + changes done by local branch. * "Accept yours", rerun the tests and verify the new outputs. This approach requires knowledge of production/test code changes in "theirs" branch. However, if such changes resulted in straightforward and repetitive output changes, like due to printing code change or fixture change, diff --git a/docs/load_balancer_support.md b/docs/load_balancer_support.md index cfb9a6b65dff6..321d0d9808aa5 100644 --- a/docs/load_balancer_support.md +++ b/docs/load_balancer_support.md @@ -14,7 +14,7 @@ protocol standard. e.g., when connecting to a local `mongos` instance, if the `loadBalancerPort` server parameter was set to 20100, the connection string must be of the form `"mongodb://localhost:20100/?loadBalanced=true"`. -`mongos` will emit appropiate error messages on connection attempts if these requirements are not +`mongos` will emit appropriate error messages on connection attempts if these requirements are not met. There are some subtle behavioral differences that these configuration options enable, chief of diff --git a/docs/logging.md b/docs/logging.md index b2f7d01c4403e..2699534001472 100644 --- a/docs/logging.md +++ b/docs/logging.md @@ -222,7 +222,7 @@ Fatal level log statements using `LOGV2_FATAL` perform `fassert` after logging, using the provided ID as assert id. `LOGV2_FATAL_NOTRACE` perform `fassertNoTrace` and `LOGV2_FATAL_CONTINUE` does not `fassert` allowing for continued execution. `LOGV2_FATAL_CONTINUE` is meant to be used when a fatal -error has occured but a different way of halting execution is desired such as +error has occurred but a different way of halting execution is desired such as `std::terminate` or `fassertFailedWithStatus`. `LOGV2_FATAL_OPTIONS` performs `fassert` by default like `LOGV2_FATAL` but this @@ -520,7 +520,7 @@ implemented as a friend function in a class with the following signature: In some cases a loggable type might be composed as a hierarchy in the C++ type system which would lead to a very verbose structured log output as every level -in the hierarcy needs a name when outputted as JSON. The attribute naming +in the hierarchy needs a name when outputted as JSON. The attribute naming abstraction system can also be used to collapse such hierarchies. Instead of making a type loggable it can instead return one or more attributes from its members by using `multipleAttrs` in `logAttrs` functions. diff --git a/docs/thread_pools.md b/docs/thread_pools.md index 75ae14797aa49..0dc7420a26d4b 100644 --- a/docs/thread_pools.md +++ b/docs/thread_pools.md @@ -4,7 +4,7 @@ A thread pool ([Wikipedia][thread_pools_wikipedia]) accepts and executes lightweight work items called "tasks", using a carefully managed group of dedicated long-running worker threads. The worker threads perform the work items in parallel without forcing each work item to assume the -burden of starting and destroying a dedicated thead. +burden of starting and destroying a dedicated thread. ## Classes