Upgrade Mill to 213 #723

lihaoyi · 2019-10-28T08:05:40Z

Overall approach:

Most modules can be upgraded to Scala 2.13 without issue, with the standard collections syntax fixes or sprinkling of .toSeq to since the plain Seq is now immutable.Seq instead of collections.Seq
Only scalanativelib and playlib cannot be upgraded to 2.13 due to dependencies; we leave those in 2.12, and turn their respective *.api modules into pure Java modules so they can be shared between both the Scala 2.12 *Worker an the Scala 2.13 *Module modules
The conversion of *.api modules is relatively straightforward: Scala collections to Java, os.Path to java.io.File, sealed trait hierarchies to Java enums. Except for one case in playlib where I convert a mill.api.Result[CompilationResult] to instead return a nullable String since the CompilationResult can be trivially constructed outside the worker
We do the Scala datatypes <-> Java datatypes conversions on each side of the *.api interface calls, to allow most of the *Module and *Worker class code to be unchanged.
We need to tweak the classloaders where playlib's playlib.worker module is loaded into to ensure it does not share any Scala classes with the parent Mill build
Tweaked the way ClassLoader.create works to allow the packages to be shared with the host environment to be customized on a per-classloader basis. This allow sharing the relevant interface classpaths for playlib and scalanativelib
Tweaked scalanativelib.testArgs and contrib.playlib.testArgs to use .assemblys rather than .compile for their worker classpaths, as the now-isolated workers need to include their entire transitive classpaths rather than just the shallow classpath of the worker module itself
scalanativelib.worker and contrib.playlib.worker now need to specify additional dependencies such as OS-Lib. These were previously leaking in from the host classloader, but that leakage has now been closed off for those worker modules
Fixed a bug in the ScoverageModule where they were relying on the Module's scalaVersion to resolve jars to run in the scoverage worker. This is incorrect, as the scoverage worker should have its scala version hardcoded to match the scalaVersion in Mills' own contrib.scoverage.worker, and be independent of the scala version of the module it is working for
Removed support for all but the most recent Dotty version
Simplified the play-json integration test build to remove some optional things (MIMA, etc.) that do not support Scala 2.13

lihaoyi · 2019-10-28T08:07:08Z

@alexarchambault I'm having trouble with the new version of coursier you put into Ammonite. It seems your coursier data types are no longer case classes, and thus cannot be trivially serialized. What should I do here?

lihaoyi mill$ mill -w __.compile
[106/1296] main.core.compile
[info] Compiling 27 Scala sources to /Users/lihaoyi/Github/mill/out/main/core/compile/dest/classes ...
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:6:73: Can't find primary constructor of coursierapi.Module
[error]   implicit lazy val modFormat: RW[coursierapi.Module] = upickle.default.macroRW
[error]                                                                         ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:7:76: Can't find primary constructor of coursierapi.Dependency
[error]   implicit lazy val depFormat: RW[coursierapi.Dependency]= upickle.default.macroRW
[error]                                                                            ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:8:48: type Attributes is not a member of package coursierapi
[error]   implicit lazy val attrFormat: RW[coursierapi.Attributes] = upickle.default.macroRW
[error]                                                ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:8:78: uPickle is trying to infer a Reader[Nothing]. That probably means you messed up
[error]   implicit lazy val attrFormat: RW[coursierapi.Attributes] = upickle.default.macroRW
[error]                                                                              ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:9:47: type Organization is not a member of package coursierapi
[error]   implicit lazy val orgFormat: RW[coursierapi.Organization] = upickle.default.macroRW
[error]                                               ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:9:79: uPickle is trying to infer a Reader[Nothing]. That probably means you messed up
[error]   implicit lazy val orgFormat: RW[coursierapi.Organization] = upickle.default.macroRW
[error]                                                                               ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:10:51: type ModuleName is not a member of package coursierapi
[error]   implicit lazy val modNameFormat: RW[coursierapi.ModuleName] = upickle.default.macroRW
[error]                                                   ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:10:81: uPickle is trying to infer a Reader[Nothing]. That probably means you messed up
[error]   implicit lazy val modNameFormat: RW[coursierapi.ModuleName] = upickle.default.macroRW
[error]                                                                                 ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:11:57: object core is not a member of package coursierapi
[error]   implicit lazy val configurationFormat: RW[coursierapi.core.Configuration] = upickle.default.macroRW
[error]                                                         ^
[error] /Users/lihaoyi/Github/mill/main/core/src/util/JsonFormatters.scala:11:95: uPickle is trying to infer a Reader[Nothing]. That probably means you messed up
[error]   implicit lazy val configurationFormat: RW[coursierapi.core.Configuration] = upickle.default.macroRW
[error]                                                                                               ^

alexarchambault · 2019-10-28T19:50:26Z

@lihaoyi New versions of Ammonite don't directly rely on coursier per se, but use its Java API instead.

But you should be able to use coursier itself directly from mill. Just depend on io.get-coursier::coursier:2.0.0-RC4-1 for example, and recover the actual (scala) coursier API. It won't conflict with the coursier stuff from Ammonite, as the coursier Java API shades the scala stuff it needs.

lihaoyi · 2019-10-29T02:28:58Z

@alexarchambault got it. Now I'm hitting this case where coursier.Resolution no longer takes multiple arguments:

    val start = Resolution(
      deps.map(mapDependencies.getOrElse(identity[Dependency](_))).toSeq,
      forceVersions = forceVersions,
      mapDependencies = mapDependencies
    )

How should I handle this?

lihaoyi · 2019-10-29T02:32:21Z

Also this

[error] /Users/lihaoyi/Github/mill/main/src/modules/Jvm.scala:427:45: type Artifact is not a member of package coursier.core
[error]       def load(artifacts: Seq[coursier.core.Artifact]) = {

lihaoyi · 2019-10-29T02:34:03Z

@alexarchambault I've pushed my latest work to this PR; could you take a look at the compile errors and help me update the coursier-related code to be compatible with the latest version of coursier? You can reproduce the compile errors via ./mill -w __.compile

alexarchambault · 2019-10-29T21:24:52Z

So alexarchambault@4de9425 fixes the coursier-related errors. These are related to the recent switch to data-class (data classes don't have a copy method, but have with* methods instead). Some constructors went away because of it too.

lihaoyi · 2019-10-31T09:54:40Z

Looks like we're going to need to convert our API modules to use purely Java types, given the disparate versions of Scala on both sides. That looks like it might be pretty annoying, might not be worth the hassle vs just waiting for everyone to get on 2.13

Ammonite-Bot · 2019-10-31T10:21:33Z

Another alternative could be to serialize the paramaters and return values of the calls across the 2.12/2.13 boundary using upickle, as either JSON or MessagePack. Also annoying in its own way, but at least we wouldn’t need to rewrite large amounts of code in Java. Most of these data types should already be serializable anyway

…

On Thu, 31 Oct 2019 at 5:54 PM, Li Haoyi ***@***.***> wrote: Looks like we're going to need to convert our API modules to use purely Java types, given the disparate versions of Scala on both sides. That looks like it might be pretty annoying, might not be worth the hassle vs just waiting for everyone to get on 2.13 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#723>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE5HBDCFQKMX5EJSF7FFJO3QRKTOHANCNFSM4JFWX5GQ> .

lihaoyi · 2020-04-14T13:43:16Z

I'm still running tests, but everything compiles and I've run some basic smoketests to validate that the approach works. In particular, all of contrib.playlib.test and scalanative.test pass on my macbook

I've rebased on top of the latest master

Review by @lefou, since you're probably the most familiar with Mill's internals at this point :)

lihaoyi · 2020-04-14T15:23:03Z

Somehow the Dotty test is blowing up. I'm just going to disable it for now, and the Dotty folks can re-enable it at their leisure. CC @smarter

[error] -- Error: /home/travis/build/lihaoyi/mill/target/worksources/mill/scalalib/HelloWorldTests/Dotty213/foo/src/Main.scala:1:0 
[error] 1 |object Main {
[error]   |^
[error]   |Recursion limit exceeded.
[error]   |Maybe there is an illegal cyclic reference?
[error]   |If that's not the case, you could also try to increase the stacksize using the -Xss JVM option.
[error]   |A recurring operation is (inner to outer):
[error]   |
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  ...
[error]   |
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala.Serializable
[error]   |  find-member scala#Predef
[error] one error found
mill.scalalib.HelloWorldTests: [27/37] foo.compile failed
mill.scalalib.HelloWorldTests: [28/37] foo.finalMainClassOpt failed
mill.scalalib.HelloWorldTests: [29/37] foo.localClasspath failed
mill.scalalib.HelloWorldTests: [31/37] foo.runIvyDeps 
mill.scalalib.HelloWorldTests: [30/37] foo.finalMainClass failed
mill.scalalib.HelloWorldTests: [32/37] foo.forkArgs 
mill.scalalib.HelloWorldTests: [34/37] foo.forkEnv 
mill.scalalib.HelloWorldTests: [35/37] foo.forkWorkingDir 
mill.scalalib.HelloWorldTests: [33/37] foo.upstreamAssemblyClasspath 
mill.scalalib.HelloWorldTests: [36/37] foo.runClasspath failed
mill.scalalib.HelloWorldTests: [37/37] foo.run failed
X mill.scalalib.HelloWorldTests.dotty213 4490ms 
  scala.MatchError: Left(Failure(Compilation failed,None)) (of class scala.util.Left)
    mill.scalalib.HelloWorldTests$.$anonfun$tests$243(HelloWorldTests.scala:949)
    mill.scalalib.HelloWorldTests$.$anonfun$tests$243$adapted(HelloWorldTests.scala:948)
    mill.scalalib.HelloWorldTests$.workspaceTest(HelloWorldTests.scala:317)
    mill.scalalib.HelloWorldTests$.$anonfun$tests$242(HelloWorldTests.scala:323)

lihaoyi · 2020-04-15T00:40:34Z

@smarter I see the following classpath being passed to zinc during compilation

/Users/lihaoyi/Github/mill/target/workspace/mill/scalalib/HelloWorldTests/eval/dotty213/foo/compile/dest/classes
/Users/lihaoyi/Github/mill/target/worksources/mill/scalalib/HelloWorldTests/Dotty213/foo/resources
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/scala-library/0.18.1-RC1/scala-library-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.13/1.2.0/scala-xml_2.13-1.2.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-library_0.18/0.18.1-RC1/dotty-library_0.18-0.18.1-RC1.jar

I see there's a scala-library-2.13.0 jar present. Should that be a 2.12 jar? Or does Dotty support both standard libraries?

lihaoyi · 2020-04-15T00:45:06Z

Hmm in master, without this PR, I see the following classpath:

/Users/lihaoyi/Github/mill/target/workspace/mill/scalalib/HelloWorldTests/eval/dotty213/foo/compile/dest/classes
/Users/lihaoyi/Github/mill/target/worksources/mill/scalalib/HelloWorldTests/Dotty213/foo/resources
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-library_0.18/0.18.1-RC1/dotty-library_0.18-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/scala-library/0.18.1-RC1/scala-library-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.13/1.2.0/scala-xml_2.13-1.2.0.jar

lihaoyi · 2020-04-15T00:46:12Z

Looks like the same contents in both cases

lihaoyi · 2020-04-15T00:51:21Z

The compiler's own classpath is the same in both cases:

/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/jline/jline-reader/3.9.0/jline-reader-3.9.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/jline/jline-terminal/3.9.0/jline-terminal-3.9.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-sbt/util-interface/1.2.2/util-interface-1.2.2.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/jline/jline-terminal-jna/3.9.0/jline-terminal-jna-3.9.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/scala-library/0.18.1-RC1/scala-library-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-sbt/compiler-interface/1.2.5/compiler-interface-1.2.5.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-interfaces/0.18.1-RC1/dotty-interfaces-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/modules/scala-asm/6.0.0-scala-1/scala-asm-6.0.0-scala-1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-library_0.18/0.18.1-RC1/dotty-library_0.18-0.18.1-RC1.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-compiler_0.18/0.18.1-RC1/dotty-compiler_0.18-0.18.1-RC1.jar

I wonder if the problem is with the new version of Zinc 1.4.0-M1 that I'm using

smarter · 2020-04-15T01:00:36Z

Dotty only supports the 2.13 standard library. It's possible there's something fishy with the new zinc yeah, if there was a version of sbt compiled against it we could test that hypothesis.

smarter · 2020-04-15T01:03:04Z

I see the following classpath:

How are you checking this? If you haven't, try adding -Ylog-classpath to the compiler flags to see what the compiler actually sees for real.

smarter · 2020-04-15T01:04:34Z

if there was a version of sbt compiled against it we could test that hypothesis.

Oh, I guess you could just try the new zinc without any of the other changes in this PR since it should be cross-compiled against 2.12.

lihaoyi · 2020-04-15T01:05:14Z

@smarter those are the classpath being passed to Zinc's IncrementalCompilerImpl.input, and allJars being passed to Zinc's ScalaInstance. I can try log-classpath see if it differs

smarter · 2020-04-15T01:13:14Z

Oh, so there's some zinc settings related to filtering out the library jar(s). And a while back, I changed library jar handling in zinc to allow multiple library jars (since both scala-library and dotty-library are library jars for dotty). It seems that you're still passing a single libraryJar to ScalaInstance when there's another constructor that takes a libraryJars parameter to pass both, fixing that might help.

smarter · 2020-04-15T01:19:29Z

Oh, so there's some zinc settings related to filtering out the library jar(s).

I see you're passing ClasspathOptionsUtil.boot, that's supposed to remove the library jar (so here just scala-library since that's the one passed to libraryJar) from the compiler classpath and add it to the compiler bootclasspath, but doing this shouldn't break anything (and I guess worked OK so far). -Ylog-classpath should tell us more on what is going on.

lihaoyi · 2020-04-15T01:44:46Z

So passing in -Ylog-classpath on this PR gives me this

Classpath built from (Setting(-bootclasspath,Override location of bootstrap class files.,,,List(),,List(),List(),None) Setting(-classpath,Specify where to find user class files.,.,,List(),,List(),List(),None) Setting(-d,destination for generated classfiles.,.,directory|jar,List(),,List(),List(),None) Setting(-Ylog-classpath,Output information about what classpath is being applied.,false,,List(),,List(),List(),None))
Defaults: object Defaults {
  scalaHome            =
  javaBootClassPath    =
  scalaLibDirFound     = None
  scalaLibFound        =
  scalaBootClassPath   =
  scalaPluginPath      = misc/scala-devel/plugins
}
Calculated: object Calculated {
  scalaHome            =
  priorityClassPath    =
  javaBootClassPath    =
  javaExtDirs          =
  javaUserClassPath    =
  useJavaClassPath     = false
  scalaBootClassPath   = /Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/scala-library/0.18.1-RC1/scala-library-0.18.1-RC1.jar
  scalaExtDirs         =
  userClassPath        =
/Users/lihaoyi/Github/mill/target/workspace/mill/scalalib/HelloWorldTests/eval/dotty213/foo/compile/dest/classes
/Users/lihaoyi/Github/mill/target/worksources/mill/scalalib/HelloWorldTests/Dotty213/foo/resources
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.13/1.2.0/scala-xml_2.13-1.2.0.jar
/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-library_0.18/0.18.1-RC1/dotty-library_0.18-0.18.1-RC1.jar
  sourcePath           =
}
After java boot/extdirs classpath has 4 entries:
  ZipArchiveClassPath(/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/scala-library/0.18.1-RC1/scala-library-0.18.1-RC1.jar)
  DirectoryClassPath(/Users/lihaoyi/Github/mill/target/workspace/mill/scalalib/HelloWorldTests/eval/dotty213/foo/compile/dest/classes)
  ZipArchiveClassPath(/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.13/1.2.0/scala-xml_2.13-1.2.0.jar)
  ZipArchiveClassPath(/Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/ch/epfl/lamp/dotty-library_0.18/0.18.1-RC1/dotty-library_0.18-0.18.1-RC1.jar)

Not sure how to read this; @smarter does it look like anything is missing?

lihaoyi · 2020-04-15T01:46:37Z

It seems the /Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar I am passing in as part of classpath is missing from the -Ylog-classpath output!

lihaoyi · 2020-04-15T01:48:37Z

I don't see any ScalaInstance constructor that allows libraryJars taking a Seq of inputs; maybe that's only present in a newer version of Zinc?

smarter · 2020-04-15T02:04:30Z

It seems the /Users/lihaoyi/.coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar I am passing in as part of classpath is missing from the -Ylog-classpath output!

Oh yeah, looks like both scala-library-0.18 and scala-library-2.13 got filtered out, but only scala-library-0.18 got added back to the bootclasspath. scala-library-0.18 is just a dummy jar that depends on the correct dotty-library/scala-library, not using it at all would simplify things and maybe fix the problem.

I don't see any ScalaInstance constructor that allows libraryJars taking a Seq of inputs;

It takes an Array, not a Seq: https://github.com/sbt/zinc/blob/0fcb33d74af50da15e01f5adfd39ce2d241f50e5/internal/zinc-classpath/src/main/scala/sbt/internal/inc/ScalaInstance.scala#L38

lihaoyi · 2020-04-15T02:08:03Z

Got it, hardcoding libraryJar = libraryJarNameGrep(compilerClasspath, "2.13.0").toIO, seems to do the trick

lihaoyi · 2020-04-15T07:25:25Z

@lefou all tests are green on travis!

lefou

Looks good to me.

smarter · 2020-04-15T12:46:22Z

scalalib/worker/src/ZincWorkerImpl.scala

-        libraryJar = libraryJarNameGrep(compilerClasspath, scalaVersion).toIO,
+        libraryJar = libraryJarNameGrep(
+          compilerClasspath,
+          if (isDotty(scalaVersion)) "2.13.0" else scalaVersion


⛔ This is going to do the wrong thing with more recent versions of dotty which depend on 2.13.1, and will break again when we switch to 2.13.2, etc. The root problem here is that you have this scala-library-0.xx jar at all, you shouldn't be using it or depending on it in any way. You should depend on dotty-library which depends on the appropriate scala-library-2.13 and that's all.

@smarter Thanks for reviewing it!

@lihaoyi Are you going to do something about it? If not, we might just open a ticket?

@lefou Perhaps just open a ticket for now? Then if someone wants to fix it to support a new version of Dotty, and adjust/add to the test suite, they can submit a PR to do so.

@smarter why does the minor version of scala-library matter for Dotty? Isn't scala-library meant to be backwards and forwards binary compatible between minor versions?

why does the minor version of scala-library matter for Dotty?

You're calling libraryJarNameGrep which is going to look for a jar called scala-library-2.13.0 among the dependencies of the dotty compiler, since recent versions of the dotty compiler depend on scala-library-2.13.1, it won't find it. (and we do have to bump the version of scala-library we depend on sometimes, e.g. for scala/scala3#8480 we'll need to depend on 2.13.2)

lihaoyi added 2 commits October 28, 2019 15:47

wip

be44722

wip

b19d3f4

.

64e8761

lihaoyi added 5 commits October 30, 2019 09:33

Fix coursier-related compilation errors (#725)

49e6c7e

mill -w __.compile passes

b24e4ec

bump scalaj-http version

aaf850e

scalalib-213

fcedee5

.

4561bda

lefou added the rebase-needed This pull request needs a git rebase before a merge is possible label Mar 31, 2020

lihaoyi added 5 commits April 14, 2020 18:54

build.sc works after merging master

ddd0de9

__.compile passes

8b74392

wip

666c177

merge

0964de8

fix

995b857

lihaoyi requested a review from lefou April 14, 2020 13:40

lefou removed the rebase-needed This pull request needs a git rebase before a merge is possible label Apr 14, 2020

lihaoyi added 4 commits April 14, 2020 22:12

.

18c8800

fix tut test args

a365290

remve special case to support 2.13.0-M3

b3895ff

disable dotty test; doesn't work for some reason

5e2ce1f

.

ea6ad93

fix scalajs test

7752afe

lihaoyi added 4 commits April 15, 2020 10:09

fix dotty213 test, delete old dotty tests

8212946

fix

6fb7af4

fix

f3b6383

bump-utest

911295b

lefou approved these changes Apr 15, 2020

View reviewed changes

lefou linked an issue Apr 15, 2020 that may be closed by this pull request

Upgrade to Scala 2.13.0 #630

Closed

lihaoyi merged commit 5be5701 into master Apr 15, 2020

lefou added this to the after 0.6.1 milestone Apr 15, 2020

smarter reviewed Apr 15, 2020

View reviewed changes

lefou modified the milestones: after 0.6.1, 0.7.0 Apr 22, 2020

lefou deleted the 213 branch November 25, 2020 15:50

Uh oh!

Upgrade Mill to 213 #723

Upgrade Mill to 213 #723

Uh oh!

Conversation

lihaoyi commented Oct 28, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lihaoyi commented Oct 28, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexarchambault commented Oct 28, 2019

Uh oh!

lihaoyi commented Oct 29, 2019

Uh oh!

lihaoyi commented Oct 29, 2019

Uh oh!

lihaoyi commented Oct 29, 2019

Uh oh!

alexarchambault commented Oct 29, 2019

Uh oh!

lihaoyi commented Oct 31, 2019

Uh oh!

Ammonite-Bot commented Oct 31, 2019 via email

Uh oh!

lihaoyi commented Apr 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lihaoyi commented Apr 14, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

smarter commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lihaoyi commented Apr 15, 2020

Uh oh!

lefou left a comment

Choose a reason for hiding this comment

Uh oh!

smarter Apr 15, 2020

Choose a reason for hiding this comment

Uh oh!

lefou Apr 16, 2020

Choose a reason for hiding this comment

Uh oh!

lihaoyi Apr 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

smarter Apr 16, 2020

Choose a reason for hiding this comment

Uh oh!

Reviewers

lihaoyi commented Oct 28, 2019 •

edited

Loading

lihaoyi commented Oct 28, 2019 •

edited

Loading

lihaoyi commented Apr 14, 2020 •

edited

Loading

lihaoyi commented Apr 15, 2020 •

edited

Loading

lihaoyi Apr 16, 2020 •

edited

Loading