SI-2066 Plug a soundness hole higher order type params, overriding

PolyType-s parameterized by higher order type parameters (HOTPs)
should only be relatable with <:< or =:= if the variances of their
type parameters line up. This is only enforced for HOTPs defined in
method type arguments.

Invariant type parameters subsume variant ones. Concretely, as
described by @S11001001:

> A method taking [F[_]] can implement a method taking [F[+_]].
> Likewise, a method taking [F[_[+_]]] can implement a method
> taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]],
> and so on, the variance subsumption flipping at each step.
>
> This is just the opposite of the variance for passing type
> parameters to either instantiate types or call methods; a F[+_]
> is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument,
> and so on.
>
> All of the above rules can be duplicated for contravariant positions
> by substituting - for +. Also, something similar happens for
> weakening/strengthening bounds, I believe.

These cases are tested in the `// okay` lines in `neg/t2066.scala`.

1 files changed, 5 insertions, 0 deletions

diff --git a/test/files/neg/t2066b.check b/test/files/neg/t2066b.check
new file mode 100644
index 0000000000..097c44fef3
--- /dev/null
+++ b/test/files/neg/t2066b.check
@@ -0,0 +1,5 @@
+t2066b.scala:7: error: overriding method f in trait A of type [T[_]](x: T[Int])T[Any];
+ method f has incompatible type
+	 def f[T[+_]](x : T[Int]) : T[Any] = x
+             ^
+one error found