Merge branch 'master' into develop
diff --git a/docs/_nav.yml b/docs/_nav.yml
index 1a74d9a..3a7dbfc 100644
--- a/docs/_nav.yml
+++ b/docs/_nav.yml
@@ -1,9 +1,9 @@
-- md: basics.md
- url: basics.html
- title: Basics
- md: coroutines-guide.md
url: coroutines-guide.html
title: Coroutines Guide
+- md: basics.md
+ url: basics.html
+ title: Basics
- md: cancellation-and-timeouts.md
url: cancellation-and-timeouts.html
title: Cancellation and Timeouts
diff --git a/docs/channels.md b/docs/channels.md
index a99be78..5495ef4 100644
--- a/docs/channels.md
+++ b/docs/channels.md
@@ -133,7 +133,7 @@
You could abstract such a producer into a function that takes channel as its parameter, but this goes contrary
to common sense that results must be returned from functions.
-There is a convenience coroutine builder named [produce] that makes it easy to do it right on producer side,
+There is a convenient coroutine builder named [produce] that makes it easy to do it right on producer side,
and an extension function [consumeEach], that replaces a `for` loop on the consumer side:
<div class="sample" markdown="1" theme="idea" data-highlight-only>
@@ -179,7 +179,7 @@
</div>
And another coroutine or coroutines are consuming that stream, doing some processing, and producing some other results.
-In the below example the numbers are just squared:
+In the example below, the numbers are just squared:
<div class="sample" markdown="1" theme="idea" data-highlight-only>
@@ -219,7 +219,7 @@
-->
> All functions that create coroutines are defined as extensions on [CoroutineScope],
-so that we can rely on [structured concurrency](https://github.com/Kotlin/kotlinx.coroutineskotlinx.coroutines/blob/master/docs/composing-suspending-functions.md#structured-concurrency-with-async) to make
+so that we can rely on [structured concurrency](https://kotlinlang.org/docs/reference/coroutines/composing-suspending-functions.html#structured-concurrency-with-async) to make
sure that we don't have lingering global coroutines in our application.
### Prime numbers with pipeline
diff --git a/docs/coroutine-context-and-dispatchers.md b/docs/coroutine-context-and-dispatchers.md
index 25761b0..2998b46 100644
--- a/docs/coroutine-context-and-dispatchers.md
+++ b/docs/coroutine-context-and-dispatchers.md
@@ -52,7 +52,7 @@
the corresponding coroutine uses for its execution. Coroutine dispatcher can confine coroutine execution
to a specific thread, dispatch it to a thread pool, or let it run unconfined.
-All coroutines builders like [launch] and [async] accept an optional
+All coroutine builders like [launch] and [async] accept an optional
[CoroutineContext](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines.experimental/-coroutine-context/)
parameter that can be used to explicitly specify the dispatcher for new coroutine and other context elements.
@@ -594,7 +594,7 @@
For [`ThreadLocal`](https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html),
[asContextElement] extension function is here for the rescue. It creates an additional context element,
-which keep the value of the given `ThreadLocal` and restores it every time the coroutine switches its context.
+which keeps the value of the given `ThreadLocal` and restores it every time the coroutine switches its context.
It is easy to demonstrate it in action:
diff --git a/docs/exception-handling.md b/docs/exception-handling.md
index 57ad58b..b3e0e80 100644
--- a/docs/exception-handling.md
+++ b/docs/exception-handling.md
@@ -47,7 +47,7 @@
Coroutine builders come in two flavors: propagating exceptions automatically ([launch] and [actor]) or
exposing them to users ([async] and [produce]).
-The former treat exceptions as unhandled, similar to Java's `Thread.uncaughExceptionHandler`,
+The former treat exceptions as unhandled, similar to Java's `Thread.uncaughtExceptionHandler`,
while the latter are relying on the user to consume the final
exception, for example via [await][Deferred.await] or [receive][ReceiveChannel.receive]
([produce] and [receive][ReceiveChannel.receive] are covered later in [Channels](https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/channels.md) section).
@@ -254,7 +254,7 @@
> One of the solutions would have been to report each exception separately,
but then [Deferred.await] should have had the same mechanism to avoid behavioural inconsistency and this
-would cause implementation details of a coroutines (whether it had delegate parts of its work to its children or not)
+would cause implementation details of a coroutines (whether it had delegated parts of its work to its children or not)
to leak to its exception handler.
<!--- INCLUDE