`asInstanceOf` causes type mismatch error when used in method argument position

Compiler version

3.0.0

Minimized code

object X {

  class CA[A]
  type C = CA[_]
  val c: C = ???
  def f[A](r: CA[A]) = ()

  // works
  f(c)

  // works
  val x = c.asInstanceOf[C]
  f(x)

  // error
  f(c.asInstanceOf[C])

  // works
  f(c.asInstanceOf[c.type])
}

Output

[error] -- [E007] Type Mismatch Error: a.scala:16:18 
[error] 16 |  f(c.asInstanceOf[C])
[error]    |    ^^^^^^^^^^^^^^^^^
[error]    |    Found:    X.C
[error]    |    Required: X.CA[A]
[error]    |
[error]    |    where:    A is a type variable
[error] one error found

Expectation

No error.

[liufengyun]

This is a bug in the compiler, as the following works:

object O {

  class CA[A](var x: A)
  type C = CA[_]

  val c: CA[_] = CA(5)
  def f[A](r: CA[A]): A = r.x

  def g(): CA[_] = CA("hello")

  f(g())
  f(c.asInstanceOf[CA[_]])
}

We have two places where capture conversion kicks in. One is in typer that handles top-level wildcards. One is in TypeComparer which only works for a stable path.

The reason why the first mechanism does not work for f(c.asInstanceOf[C]) is that we forget to dealias in captureWildcards:

https://github.com/lampepfl/dotty/blob/fcd837addc5b466b055da069960e48c5d4d5c1dc/compiler/src/dotty/tools/dotc/typer/Inferencing.scala#L506-L530

With the following change, the original code compiles:

--- a/compiler/src/dotty/tools/dotc/typer/Inferencing.scala
+++ b/compiler/src/dotty/tools/dotc/typer/Inferencing.scala
@@ -503,7 +503,7 @@ object Inferencing {
     *  $i is a skolem of type `scala.internal.TypeBox`, and `CAP` is its
     *  type member. See the documentation of `TypeBox` for a rationale why we do this.
     */
-  def captureWildcards(tp: Type)(using Context): Type = tp match {
+  def captureWildcards(tp: Type)(using Context): Type = tp.dealias match {
     case tp @ AppliedType(tycon, args) if tp.hasWildcardArg =>

[japgolly]

This isn’t the first time I’ve reported simple substitution not holding (see here and here). Issues like this are 100% going to be considered Scala 3 puzzlers, which is such a shame after such great work was done to close out so many Scala 2 puzzlers and quirks.