Ensure that partest runs bootstrapped Dotty.

[DarkDimius]

This pr is going to fail. Putting it here so that we can collaboratively fix regressions that stop us from running partest bootstrapped again.

[DarkDimius]

One issue was pointed out by @odersky in #1114 that refernces to needed companions get dropped. I believe that this could be a bug due to fact that DropEmptyCompanions is in the miniphase block where all the scopes\members&info are wrong and lying.

[DarkDimius]

The other issue is #1116

[odersky]

@DarkDimius: No, unfortunately the problem is different and harder. dropEmptyCompanions does not look in other compilation units when it decides to drop a companion object. Concretely: We drop an innner companion object in Phases, but the surviving reference is in Contexts. I have to idea how to do this in the face of separate compilation.

It seems it is time to go back to the idea of not generating synthetic companion objects eagerly in the first place. We can do one of the following things:

• generate companion objects on demand only, when a phase requires them, or
• not put generated stuff in companion objects, make it static instead.

[DarkDimius]

but the surviving reference is in Contexts

why would Contexts need a reference to Phases$PhasesBase$TerminalPhase$, if Phases$PhasesBase didn't need it so that it was able to eliminate it? I'd like to have a look in more detail to understand what's happening here.

I do agree that making all synthetic lazy-vals and value-class needed methods\fields is a better way to go, while generating companions on-demand is easier.

[odersky]

It's the initialization of the lazy val in the implementing class, I think.

On Sat, Feb 20, 2016 at 2:44 PM, Dmitry Petrashko [email protected]
wrote:

but the surviving reference is in Contexts

why would Contexts need a reference to Phases$PhasesBase$TerminalPhase$,
if Phases$PhasesBase didn't need it so that it was able to eliminate it?
I'd like to have a look in more detail to understand what's happening here.

I do agree that making all synthetic lazy-vals and value-class needed
methods\fields is a better way to go, while generating companions on-demand
is easier.

—
Reply to this email directly or view it on GitHub
#1115 (comment).

Martin Odersky
EPFL

[odersky]

@DarkDimius can you revert the workaround commit and rebase?

[odersky]

Looks like the partest project needs to be recompiled. It still defines default methods with the long names.

[DarkDimius]

The CI does not mainain any state, recompiling would not help.
This branch is rebased over #1119
Partest at the moment is compiled by scalac(as it's part of tests) and Dotty is compiled by dotty.
The failure seems to be a different manifestation of #1116

[odersky]

It is a different error, also having to do with default getters. It seems we really did not have very good test coverage for this, otherwise we should have found the errors before.

[odersky]

Previous commit setting type explicitly was a red herring. Without it, the test defaultGetters does not compile. The fix has to lies elsewhere.

[odersky]

/rebuild

[odersky]

/rebuild

[odersky]

Repeated GC overhead limit exceeded failures.

[smarter]

There's also some kind of pattern-matching bug: https://gist.github.com/smarter/1d04f869870df03d0976

[smarter]

dotty-staging@00638e9 should be removed or reverted from this PR now that we know we're using the correct classes.

[DarkDimius]

There's also some kind of pattern-matching bug: https://gist.github.com/smarter/1d04f869870df03d0976

I'm not sure if this is a bug in patmat. The exception correctly indicates a missing match for NoType$

[smarter]

Indeed, the corresponding line is https://github.com/dotty-staging/dotty/blob/7bf01004020106ec1639df61268afdf841694e1e/src/dotty/tools/dotc/core/SymDenotations.scala#L782 so it seems like the bootstrapped compiler is able to produce a ClassInfo for a module without a self-type, even though we should always have one.

[odersky]

/rebuild

[odersky]

Once #1289 is merged, this should be rebased and tried again. My attempts at manual bootstrap work fine.

[DarkDimius]

@odersky. I've rebased it as you've asked. It fails on 3 tests, including the defaultGetters added by you in this PR. Could you take it from here?

[odersky]

I am seeing an OOM in validate-partest.

[odersky]

/rebuild

[retronym]

Tracking the infrastructure problem (I also saw it on my Scala PR an hour ago) as scala/scala-jenkins-infra#181