Less verbose partest

[vsalvis]

Caveats for partest command line options described here: #558 (comment)

Added partest-only sbt target that doesn't run the other (JUnit etc.) tests, only the tests.scala JUnit test to generate the files and then partest them. Same partest command line options can be used.

Added redirection of compiler console output into .clog file, which is appended to error output when using --verbose.

[DarkDimius]

/rebuild

[retronym]

Needs a rebase, I think.

[DarkDimius]

It needs to rebase over non-merged-yet #591

[vsalvis]

Waiting for #591 to be merged, then will rebase.

The run/byNameVarargs test fails at runtime with:

java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:
    Test$.$anonfun$$init$$8()I @0: aload_0
  Reason:
    Type top (current frame, locals[0]) is not assignable to reference type
  Current Frame:
    bci: @0
    flags: { }
    locals: { }
    stack: { }
  Bytecode:
    0x0000000: 2aba 00b2 0000 b600 b4ac               

    at Test.main(i499.scala)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...

[DarkDimius]

I've disabled byNameVarargs in #591, That's a non-blocking issue that looks like non trivial one.

[DarkDimius]

@vsalvis could you please rebase over current master?

[vsalvis]

@DarkDimius now it's ready to be merged, I fixed the strange chars and added a few lines to get better debugging output should it happen again. All generated scala and java files will now have the do not edit header.

[DarkDimius]

Having a limitation only using ANSI in comments seems too restrictive.
@vsalvis, can you try to rebase over #594?

[DarkDimius]

/rebuild

[vsalvis]

@DarkDimius rebase works!

[DarkDimius]

@vsalvis Glad to hear) I'll review this PR today.

[DarkDimius]

@vsalvis, nice job. Merging. Partest still runs sequential, am I right? Could you have a look on making it run in parallel, given that now we have CI that has more than 1.5 core?

[vsalvis]

To run in parallel just flip the runTestsInParallel flag in DPConfig.scala. But the compiler still dies, with errors such as:

java.lang.AssertionError: assertion failed: Bad superClass for class Number: val <none>
at scala.Predef$.assert(Predef.scala:165)
at scala.tools.nsc.backend.jvm.BTypesFromSymbols.scala$tools$nsc$backend$jvm$BTypesFromSymbols$$setClassInfo(BTypesFromSymbols.scala:69)
at scala.tools.nsc.backend.jvm.BTypesFromSymbols$$anonfun$classBTypeFromSymbol$4.apply(BTypesFromSymbols.scala:63)

or:

java.lang.AssertionError: assertion failed: ClassBType.info not yet assigned: Lscala/Predef$;
at scala.Predef$.assert(Predef.scala:165)
at scala.tools.nsc.backend.jvm.BTypes$ClassBType.info(BTypes.scala:600)
at scala.tools.nsc.backend.jvm.BTypes$ClassBType.isNestedClass(BTypes.scala:654)
at scala.tools.nsc.backend.jvm.BCodeHelpers$BCInnerClassGen$class.getClassBTypeAndRegisterInnerClass(BCodeHelpers.scala:244)

or:

findMember exception for ThisType(TypeRef(ThisType(TypeRef(NoPrefix,core)),ConstraintRunInfo)) member Constraint
exception occurred while typechecking /Users/vera/git/dotty/tests/partest-generated/pos/core/ConstraintRunInfo.scala

findMember exception for ClassInfo(NoPrefix, module class <root>) member scala
exception caught when loading module class package$: java.lang.AssertionError: assertion failed
findMember exception for TermRef(ThisType(TypeRef(NoPrefix,<root>)),scala) member <empty>
exception occurred while typechecking /Users/vera/git/dotty/tests/partest-generated/pos/curried.scala

[DarkDimius]

But are you running several instances of same compiler in parallel(this is not supported) or spawning a compiler-per-thread?

[vsalvis]

I'm not sure what the difference is... Each thread takes callables from the queue, and each callable calls new Compiler.newRun.compile(...). So I guess these would be several instances of the same compiler? What do you mean by spawning a compiler-per-thread?

[DarkDimius]

when you call newRun you pass it an implicit Context, and that could create conflicts between threads.
Could you please point me to place where new Compiler.newRun.compile(...). happens?

[vsalvis]

Runner.attemptCompile calls newCompiler.compile here
newCompiler is overriden to be new dotty.partest.DPDirectCompiler(this) here
DPDirectCompiler creates the new context and calls dotty.tools.dotc.Main.process here
which is Driver.process which does the new Compiler.newRun.compile here

So every call has a new instance of DPDirectCompiler, so it should also have a new context? Maybe something is wrong with how I create the context, I copied that from DottyTest