Drop requirement that self types are closed

[odersky]

#702 introduced a requirement that self types are closed. This means

If trait X has self type S and C is a class symbol of S, then S also conforms
to the self type of C.

An example that violates this requirement is

trait X { self: Y => } // error: missing requirement: self type Y & X of trait X does not conform to self type Z of required trait Y
trait Y { self: Z => }
trait Z

But it's no longer clear what the requirement should achieve. If we let the example above typecheck and try to implement X with something like

class C extends X, Y

we would at that point get an error saying that C does not conform to the self type Z of Y. So it would have to be

class C extends X, Y, Z

and this one looks fine.

The original change in #702 was made to avoid a crash in pending/run/t7933.scala. Unfortunately, we cannot reproduce this anymore since it depends on nsc.interpreter, which is no longer part of Scala 2.13.

Since we are no longer sure what the restriction should achieve I think it's better to drop it for now. If people discover problems with code that uses "open" self types, we can try to fix those problems, and if that does not work, would fallback re-instituting the restriction. It's not ideal, but I don't see another way.

Fixes #16407

[odersky]

If someone manages to revive t7933.scala that would be very helpful. It's in pending/run. Here is the code:

mport scala.tools.nsc.interpreter.IMain

object Test extends App {
  val engine = new IMain.Factory getScriptEngine()
  engine.asInstanceOf[IMain].settings.usejavacp.value = true
  val res2 = engine.asInstanceOf[javax.script.Compilable]
  res2 compile "8" eval()
  val res5 = res2 compile """println("hello") ; 8"""
  res5 eval()
  res5 eval()
}

[sjrd]

I guess the intention is to protect against situations like this:

trait X { self: Y =>
  val a = g() // what's the type of this val!?
  f(a)
}
trait Y { self: Z =>
  type B = A
  def f(a: B): Unit = ()
  def g(): A = ???
}
trait Z {
  type A
}

When computing the type of B as seen from X.this, we can end up with X.this.A. What does that mean when the self type of X is X & Y, which does not have a type member A?

[odersky]

@sjrd Ah yes, I think that was the crucial counter-example. But we are already dealing with it gracefully:

-- Error: i16407.scala:2:2 -----------------------------------------------------
2 |  f(g())
  |  ^
  |cannot resolve reference to type (X.this : Y & X).A
  |the classfile defining the type might be missing from the classpath
  |or the self type of (X.this : Y & X) might not contain all transitive dependencies
-- Error: i16407.scala:2:4 -----------------------------------------------------
2 |  f(g())
  |    ^
  |cannot resolve reference to type (X.this : Y & X).A
  |the classfile defining the type might be missing from the classpath
  |or the self type of (X.this : Y & X) might not contain all transitive dependencies
2 errors found

So I think we don't need a separate test in RefChecks (which would come later anyway).

[sjrd]

The comments in this pos file are not accurate. They say there's an error but clearly there isn't.

[sjrd]

Same here. There is no error anymore.

[odersky]

True. But we do leave the old errors in anyway if a neg test gets moved to pos as a documentation what went wrong before. That's done for many other pos tests as well.

[sjrd]

Ah OK. I did not know that. All good, then.