Merge branch 'master' into develop

Author: qwwdfsad

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

docs/channels.md

@@ -133,7 +133,7 @@ This is a part of _producer-consumer_ pattern that is often found in concurrent
 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 @@ fun CoroutineScope.produceNumbers() = produce<Int> {
 </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 @@ Done!
 -->
 
 > 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

docs/coroutine-context-and-dispatchers.md

@@ -52,7 +52,7 @@ Coroutine context includes a _coroutine dispatcher_ (see [CoroutineDispatcher])
 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 @@ are not bound to any particular thread, it is hard to achieve it manually withou
 
 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:
 

docs/exception-handling.md

@@ -47,7 +47,7 @@ coroutine throw an exception?
 
 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 @@ So, additional exceptions are suppressed.
 
 > 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