Fix checkKindBoundsHK for higher kinds

[joroKr21]

We need to flip the direction of the checks on every other level.
This is similar to contravariance of higher-order function types.

Another option would be to heed the comment:

          // Their arguments use different symbols, but are
          // conceptually the same. Could also replace the types by
          // polytypes, but can't just strip the symbols, as ordering
          // is lost then.

although I don't understand the last sentence - what ordering?
If we switch to PolyTypes we would lose the detailed error messages,
but I think this is what Scala 3 does.

fixes scala/bug#2067, fixes scala/bug#12242
This would probably need a community build

[lrytz]

probably need a community build

cc @SethTisue

[SethTisue]

queued: https://scala-ci.typesafe.com/job/scala-2.13.x-jdk11-integrate-community-build/2343/

[SethTisue]

If we switch to PolyTypes we would lose the detailed error messages,
but I think this is what Scala 3 does

It seems maybe-implied by this remark, but just to confirm: does this PR bring Scala 2 and Scala 3 in closer alignment? (Should scala/bug#2067 be labeled fixed-in-dotty?)

[joroKr21]

It seems maybe-implied by this remark, but just to confirm: does this PR bring Scala 2 and Scala 3 in closer alignment? (Should scala/bug#2067 be labeled fixed-in-dotty?)

@SethTisue yes, it's fixed in dotty:

Starting scala3 REPL...
scala> trait A[B[D[X, Y <: X]]]
     | trait C[E[T, S]]
     | type Bad = A[C]
3 |type Bad = A[C]
  |             ^
  |         Type argument C does not conform to upper bound [D[X, Y]] =>> Any

scala> trait A[T[_[_]]]
     | trait C[X[+_]]
     | type Bad = A[C]
3 |type Bad = A[C]
  |             ^
  |        Type argument C does not conform to upper bound [_$1[_$2]] =>> Any

Note that the error messages are not very informative.
It's also evident that dotty is reusing type lambdas for kind conformance.

On this branch of scalac:

Welcome to Scala 2.13.5-20201224-113823-22fc021 (OpenJDK 64-Bit Server VM, Java 11.0.9).
Type in expressions for evaluation. Or try :help.

scala> trait A[B[D[X, Y <: X]]]
     | trait C[E[T, S]]
     | type Bad = A[C]
       type Bad = A[C]
                  ^
On line 3: error: kinds of the type arguments (C) do not conform to the expected kinds of the type parameters (type B) in trait A.
       C's type parameters do not match type B's expected parameters:
       type Y's bounds <: X are stricter than type S's declared bounds >: Nothing <: Any

scala> trait A[T[_[_]]]
     | trait C[X[+_]]
     | type Bad = A[C]
       type Bad = A[C]
                  ^
On line 3: error: kinds of the type arguments (C) do not conform to the expected kinds of the type parameters (type T) in trait A.
       C's type parameters do not match type T's expected parameters:
       type _ is invariant, but type _ is declared covariant

Also I just realised this fixes scala/bug#12242 as well (it has a bad kind):

• dotty:

scala> trait Box[T]
     | trait Adapter[B <: Box[T], T]
     | trait Mixin[+A[B <: Box[S], X], S]
     | trait Super[T] extends Mixin[Adapter, T]
4 |trait Super[T] extends Mixin[Adapter, T]
  |                             ^
  |Type argument Adapter does not conform to upper bound [B <: Box[T], X] =>> Any

• this branch:

scala> trait Box[T]
     | trait Adapter[B <: Box[T], T]
     | trait Mixin[+A[B <: Box[S], X], S]
     | trait Super[T] extends Mixin[Adapter, T]
       trait Super[T] extends Mixin[Adapter, T]
                              ^
On line 4: error: kinds of the type arguments (Adapter,T) do not conform to the expected kinds of the type parameters (type A,type S) in trait Mixin.
       Adapter's type parameters do not match type A's expected parameters:
       type B (in trait Adapter)'s bounds <: Box[T] are stricter than type B's declared bounds <: Box[S]

Do you think I should add one more test?

[joroKr21]

queued: https://scala-ci.typesafe.com/job/scala-2.13.x-jdk11-integrate-community-build/2343/

"No space left on device" 🤖

[SethTisue]

https://scala-ci.typesafe.com/job/scala-2.13.x-jdk11-integrate-community-build/2345

[joroKr21]

Do you think I should add one more test?

I just did

[SethTisue]

The failure in the community build is in a known-flaky repo, so I'd call 2345 a green run.

This needs rebase before merge.

[lrytz]

unused - remove this line?

[lrytz]

also unused