Small fixes to be squashed later

Author: MarkTheHopeful

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

@@ -1786,27 +1786,27 @@ See [the type system section][Mixed-site variance] for details.
 
 We would consider a type expression `E` to be **covariant** in type parameter `X` if for every concrete type expressions `T1` and `T2` such that `T1 <: T2` it holds that `E[T1 / X] <: E[T2 / X]`. One could also say, that the *position* `X` takes in `E` is **covariant**.
 
-Not nested covariant cases are the following:
+Base covariant cases are the following:
 
 - A type expression is covariant in type parameter `X`, if this parameter is explicitly declared as `out` either [in the expression itself][Use-site variance] or [in the type declaration][Declaration-site variance];
 - Types of functions are covariant in their return type parameter, since functions have [types of kind][Function types] `FN<in A1, ..., in AN, out R>`);
 - Types of read-only properties are effectively in covariant position;
 
 In the same way, we would consider a type expression `E` to be **contravariant** in type parameter `X` if for every concrete type expressions `T1` and `T2` such that `T1 <: T2` it holds that `E[T2 / X] <: E[T1 / X]`.
 
-Not nested contravariant cases are the following:
+Base contravariant cases are the following:
 
 - A type expression is contravariant in type parameter `X`, if this parameter is explicitly declared as `in` either [in the expression itself][Use-site variance] or [in the type declaration][Declaration-site variance];
 - Types of functions are contravariant in their argument types, since functions have [types of kind][Function types] `FN<in A1, ..., in AN, out R>`;
 
 Lastly, we would consider a type expression `E` to be **invariant** in type parameter `X` if for every concrete type expressions `T1` and `T2`, `E[T1 / X] <: E[T2 / X]` holds if and only if `T1 = T2` (`T1 <: T2` and `T2 <: T1`).
 
-Not nested invariant cases are the following:
+Base invariant cases are the following:
 
 - A type expression is invariant in type parameter `X`, if this parameter is not declared as either `in` or `out` [in the expression itself][Use-site variance] or [in the type declaration][Declaration-site variance];
 - Types of mutable properties are effectively in invariant position;
 
-We will use `+` as a symbol denoting contravariance, `-` as a symbol denoting covariance and `o` as a symbol denoting invariance.
+We will use `+` as a symbol denoting covariance, `-` as a symbol denoting contravariance and `o` as a symbol denoting invariance.
 
 To infer variance of a complex type expression in a type parameter, variance composition is used, which is defined as follows:
 
@@ -1815,7 +1815,7 @@ To infer variance of a complex type expression in a type parameter, variance com
 \begin{align*}
 \texttt{+} \otimes x &= x \text{, where $x$ is any variance} \\
 \texttt{-} \otimes \texttt{+} &= \texttt{-} \\
-\texttt{-} \otimes \texttt{-} &= \texttt{-} \\ 
+\texttt{-} \otimes \texttt{-} &= \texttt{+} \\ 
 \texttt{o} \otimes x &= \texttt{o} \text{, where $x$ is any variance} \\
 x \otimes \texttt{o} &= \texttt{o} \text{, where $x$ is any variance}
 \end{align*}
@@ -1834,14 +1834,14 @@ When a type parameter has declared variance, and is used in a position of a diff
 - A covariant type parameter is used as an argument to a contravariant position;
 - A contravariant type parameter is used as an argument to a covariant position;
 
-Important remark: variance conflict does not occur if the containing declaration is private to the type parameter owner (in which case its visibility is restricted, see the [visibility][Declaration visibility] section for details).
+> Important remark: variance conflict does not occur if the containing declaration is private to the type parameter owner (in which case its visibility is restricted, see the [visibility][Declaration visibility] section for details).
 
 This applies only to member declarations of the corresponding class, extensions are not subject to this limitation.
 
-This restrictions may be lifted in particular cases by [annotating][Annotations] the corresponding type parameter usage with a special built-in annotation `kotlin.UnsafeVariance`.
+These restrictions may be lifted in particular cases by [annotating][Annotations] the corresponding type parameter usage with a special built-in annotation `kotlin.UnsafeVariance`.
 By supplying this annotation the author of the code explicitly declares that safety features that variance checks provide are not needed in this particular declarations.
 
-> Basic Examples:
+> Basic examples:
 >
 > ```kotlin
 > interface Holder<T>
@@ -1888,13 +1888,13 @@ By supplying this annotation the author of the code explicitly declares that saf
 > ```kotlin
 > class Foo<in T>() // T is contravariant
 >
-> class Bar<in S>() { // T is contravariant
+> class Bar<in S>() { // S is contravariant
 >     fun bar(x: Foo<S>) {} // ERROR, contravariant parameter in covariant usage
 >     // bar has type F1<in Foo<S>, out Unit>
 >     // Need to find variance of F1<in Foo<S>, out Unit> in S
 >     // F1<in P1, out R> is contravariant (-) in P1
 >     // Foo<S> is contravariant (-) in S
->     // Applying variance composition: - $\otimes$ - = + (covariance)
+>     // Applying variance composition: - \text{$\otimes$} - = + (covariance)
 >     // Variance of F1<in Foo<S>, out Unit> in S -- covariance
 > }
 >
@@ -1911,7 +1911,7 @@ By supplying this annotation the author of the code explicitly declares that saf
 > }
 > ```
 >
-> Remark: cases `e`, `f`, `f2`, `g`, `g2` in Basic Examples are also examples of variance composition, since they are read-only fields. However, since read-only fields are of covariance (`+`) and for any variance $x$, $\texttt{+} \otimes x = x$, it was ommited at that point.
+> Remark: cases `e`, `f`, `f2`, `g`, `g2` in "Basic examples" are also examples of variance composition, since they are read-only fields. However, since read-only fields are of covariance (`+`) and for any variance $x$, $\texttt{+} \otimes x = x$, it was omitted at that point.
 >
 > Any of these restrictions may be lifted using `@UnsafeVariance` annotation on the type argument:
 >