Disable checkNoPrivateLeaks when unpickling

[odersky]

No description provided.

[odersky]

We should try to improve the FromTasty tests and the FromTasty compilation. Right now, we have many tests failing in a pattern that seems random because we don't get a lot of info what caused the failure. You have to go to the log file to see anything. Compare with CompilationTests where the output immediately tells you what went wrong.

The other problem is that FromTasty still fails too often. The fact that we have blacklists means that there are root causes that cause a test to fail and these root causes are sometimes still poorly understood. Anytime someone changes something, it could be that some of these root causes now also applies to some test (or to a new test) and causes it to fail. I had a lot of failures that way recently, which had nothing to do with the changes, but rather exposed another way to trigger one of the root causes. Tracking down and fixing the root causes would therefore help our productivity a lot.

[smarter]

Tracking down and fixing the root causes would therefore help our productivity a lot.

Agreed. Hence my quest to fix enough things to remove the blacklists over the past week ;).

[smarter]

I have similar errors locally for another file "test4refine.scala" which passes the CI. This makes me believe that it is some compilation order dependence.

test4refine.scala is broken on OS X due to case-insensitivity issues, this is fixed by the open PR #4120, the viewtest.scala failure is probably unrelated since it fails even on the Linux CI.

[odersky]

@smarter Yes, it's really good that you are doing this!

[smarter]

I think the viewtest.scala crash is a real issue, it can be minimized to:

import scala.collection.mutable.IndexedSeqView

object Test {
  val zs: IndexedSeqView[Int, Array[Int]] = Array(1, 2, 3).view
  val cs = zs.reverse

  cs(0) += 1
}

If you replace cs(0) += 1 by val a = cs(0) you get a crash earlier in refchecks too. The issue is related to the type of cs which is inferred to zs.This even though This is declared as private[this] in https://github.com/scala/scala/blob/2.12.x/src/library/scala/collection/mutable/IndexedSeqView.scala

[Blaisorblade]

Ah, so def reverse: This is just short for def reverse: IndexedSeqView[A, Coll], and this must be expanded when compiling IndexedSeqView, since This is not in scope for clients.
The alternative would be to do the expansion when compiling users of IndexedSeqView, but that feels illegal.

In fact, private[this] members can't be refined, so it seems they can be replaced by their bounds according to variance (which also handles aliases elegantly). It seems this can be done even when typechecking their bodies, if more convenient:

class Foo {
  private[this] type A >: L <: U
  // use A in covariant/contravariant position.
  // Not sure what to do with invariant uses, do they make any sense?
  def f(x: A): A = {
    // can only assume x <: U
    // return value must be <: L
   ...body...
  }
  //that means
  //def f(x: L): U = {
  // ...body...
  //}
}

[smarter]

@odersky I managed to find the culprit, see latest commit.

[odersky]

@smarter Oops! Seems obvious in hindsight 😄

[odersky]

So we can merge this?