akhin: release review

Author: ice-phoenix

docs/src/md/kotlin.core/builtins.md

@@ -200,10 +200,10 @@ It is the type of the result of [string interpolation][String interpolation expr
   public override final fun hashCode(): Int
   ```
 
-    These methods are defined to their default behaviour: only the same entry of an enum class is equal to itself and no other object.
+    These member functions are defined to their default behaviour: only the same entry of an enum class is equal to itself and no other object.
     Hash implementation is required to be consistent, but unspecified.
 
-    > Note: the presence of these final methods ensures the semantics of equality and comparison for the enumeration objects, as they cannot be overridden by the user.
+    > Note: the presence of these final member functions ensures the semantics of equality and comparison for the enumeration objects, as they cannot be overridden by the user.
 
 * ```kotlin
   protected final fun clone(): Any

docs/src/md/kotlin.core/cdfa.md

@@ -1354,9 +1354,9 @@ There are several kinds of effects:
 **Calls-in-place** effect of function $F$ for a function-type parameter $P$ specifies that for every call of $F$ parameter $P$ will be also invoked as a function.
 This effect may also have one of the three invocation types: 
 
-- *At-least-once*, meaning that the $P$ will be invoked at least once;
-- *Exactly-once*, meaning that the $P$ will be invoked exactly once;
-- *At-most-once*, meaning that the $P$ will be invoked at most once.
+- *At-least-once*, meaning that $P$ will be invoked at least once;
+- *Exactly-once*, meaning that $P$ will be invoked exactly once;
+- *At-most-once*, meaning that $P$ will be invoked at most once.
 
 These effects change the call graph that is produced for a function call of $F$ when supplied a lambda-expression parameter for $P$.
 Without any effect, the graph looks like this:
@@ -1472,7 +1472,7 @@ If the corresponding parameter $P$ is introduced with *at-most-once* effect, thi
               v
 ```
 
-This allows the control-flow information to be extracted from lambda expression according to the policy of their invocation.
+This allows the control-flow information to be extracted from lambda expression according to the policy of its invocation.
 
 **Returns-implies-condition** effect of function $F$ for a boolean parameter $P$ specifies that if, when invoked normally, a call to $F$ returns, $P$ is assumed to be true.
 For a function call

docs/src/md/kotlin.core/coroutines.md

@@ -223,7 +223,8 @@ When the cached `intercepted` continuation is no longer needed, it is released u
 #### Coroutine intrinsics
 
 Accessing the low-level continuations is performed using a limited number of built-in intrinsic functions, which form the complete coroutine API.
-The rest of asynchronous programming support is provided as a Kotlin library.
+The rest of asynchronous programming support is provided as a Kotlin library [`kotlinx.coroutines`](https://github.com/Kotlin/kotlinx.coroutines).
+
 The complete built-in API for working with coroutines is shown below (all of these are declared in package `kotlin.coroutines.intrinsics` of the standard library).
 
 ```kotlin

docs/src/md/kotlin.core/declarations.md

@@ -645,7 +645,7 @@ Annotation classes cannot be constructed directly unless passed as arguments to
 #### Value class declaration
 
 > Note: as of Kotlin 1.5.0, user-defined value classes are an experimental feature.
-> There is, however, a number of value classes in Kotlin standard library
+> There is, however, a number of value classes in Kotlin standard library.
 
 A class may be declared a **value** class by using `inline` or `value` modifier in its declaration.
 Value classes must adhere to the following limitations:
@@ -660,8 +660,7 @@ Value classes must adhere to the following limitations:
 * They must not have any base classes besides `kotlin.Any`;
 * No other properties of this class may have backing fields.
 
-> Note: `inline` modifier for value classes is supported as a legacy feature for compatibility with Kotlin 1.4
-> experimental inline classes and will be deprecated in the future
+> Note: `inline` modifier for value classes is supported as a legacy feature for compatibility with Kotlin 1.4 experimental inline classes and will be deprecated in the future.
 
 Value classes implicitly override `equals` and `hashCode` member functions of `kotlin.Any` by delegating them to their only data property.
 Unless `toString` is overriden by the value class definition, it is also implicitly overriden by delegating to the data property.
@@ -670,7 +669,7 @@ This also means that the property may be boxed back to the value class by using
 
 Due to these restrictions, it is highly discouraged to use value classes with the [reference equality operators][Reference equality expressions].
 
-> Note: in the future versions of Kotlin, value classes may be allowed to have more than one data property
+> Note: in the future versions of Kotlin, value classes may be allowed to have more than one data property.
 
 #### Interface declaration
 

docs/src/md/kotlin.core/statements.md

@@ -67,14 +67,14 @@ All of these operators are overloadable operator functions with the following ex
 
 > Note: before Kotlin version 1.3, there were additional overloadable functions for `%` called `mod`/`modAssign`
 
-After the expansion, the resulting [function call expression][Function calls and property access] or [simple assignment][Simple assignments] is processed according to their corresponding rules and overload resolution and type checking are performed.
+After the expansion, the resulting [function call expression][Function calls and property access] or [simple assignment][Simple assignments] is processed according to their corresponding rules, and overload resolution and type checking are performed.
 If both expansion variants result in correctly resolved and inferred code, this should be reported as an operator overloading ambiguity.
 If only one of the expansion variants can be resolved correctly, this variant is picked as the correct one.
 If neither of variants result in correct code, the operator calls must be reported as unresolved.
 
 > Example: consider the following compound operator statement: `x[y] += z`.
 > The corresponding expansion variants are `x.get(y).plusAssign(z)` and `x.set(x.get(y).plus(z))` according to expansion rules for corresponding operators.
-> If, the call to `set` in the second variant results in resolution or inference error, the whole corresponding expansion is deemed unresolved and the first variant is picked if applicable.
+> If, for example, the call to `set` in the second variant results in resolution or inference error, the whole corresponding expansion is deemed unresolved and the first variant is picked if applicable.
 
 > Note: although for most real-world use cases operators `++` and `--` are similar to operator assignments, in Kotlin they are expressions and are described in the [corresponding section][Expressions-expressions] of this specification.
 

docs/src/md/kotlin.core/type-inference.md

@@ -534,7 +534,7 @@ TODO(Lambda analysis order (and the order of overloading vs type inference in ge
 
 ### Bare type argument inference
 
-Bare type argument inference is a special kind of type inference where, given a type $T$ and a constructor $TC$ the type arguments $A_0, A_1 \ldots A_N$ are inferred such that $TC[A_0, A_1 \ldots A_N] <: S$ where $T <: S$.
+Bare type argument inference is a special kind of type inference where, given a type $T$ and a constructor $TC$, the type arguments $A_0, A_1 \ldots A_N$ are inferred such that $TC[A_0, A_1 \ldots A_N] <: S$ where $T <: S$.
 It is used together with *bare types* syntax sugar that can be employed in [type checking][Type-checking expressions] and [casting][Cast expressions] operators.
 The process is performed as follows.
 
@@ -551,7 +551,7 @@ If $T$ is a nullable type $U?$, the steps given above are performed for its non-
 
 ## Builder-style type inference
 
-Some functions or parameters of functions in the standard library are annotated with the special [`@BuilderInference`][Built-in annotations] annotation, making call to these functions eligible for the special kind of type inference: **builder-style type inference**.
+Some functions or parameters of functions in the standard library are annotated with the special [`@BuilderInference`][Built-in annotations] annotation, making calls to these functions eligible for the special kind of type inference: **builder-style type inference**.
 In order to allow builder-style inference for a function parameter, this parameter must hold the following properties:
 
 - It must be of an extension-function type;