move to sbt 1.3, fix build on JDK 13+#8525
Conversation
|
Travis is failing with: which is unrelated to these changes, so I think this should be mergeable as long as Jenkins likes it /cc @eed3si9n |
|
scala.ipr.SAMPLE probably isn't right after this change, but I don't know what the procedure is for updating it, @lrytz it looks like you were the last one to regenerate that file, perhaps you could contribute that here...? |
|
@eed3si9n what do you make of this, from https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/10185/consoleFull ? |
|
Thank you for pushing this; I am counting on you to get this resolved. |
The dependency versions in this file don't need to be up to date, running |
I think SDKMAN is getting stuck. Here's my attempt at this issue - #8528 |
|
@SethTisue Ivy does some weird things when it encounters a SNAPSHOT dependency and tries to figure out the publish date (to compare or invalidate the SNAPSHOT versions). One of them is screen scraping, so maybe it somehow is doing that? Did versioning somehow change? |
ed056e4 to
1a05738
Compare
|
@eed3si9n whatever it was, it doesn't seem to be happening anymore |
|
o_O |
|
@dwijnand I'll just filter that out I guess |
|
Jenkins likes it now Travis-CI fails in the Dotty portion (which the Jenkins build lacks entirely) with: I'll try rebasing on top of #8604 and see if that helps |
|
I still get the UPDATE: I upgraded sbt-dotty from 0.3.3 to 0.3.4, but it didn't help. @anatoliykmetyuk any idea what's going on here? I see there is some fiddly stuff around this in |
|
The error is emitted by Dotty compiler when it tries to locate the symbol for |
|
@SethTisue Here's an extra commit on top of your branch that fixes the issue: smarter@1886950 |
|
... turns out I can push to that branch myself, so I did :). |
This corresponds to scala/scala#8525.
This corresponds to scala/scala#8525.
This corresponds to scala/scala#8525.
This corresponds to scala/scala#8525.
This corresponds to scala/scala#8525.
This corresponds to scala/scala#8525.
|
CI liked it on 1.3.6; I added one more commit to go to 1.3.7. if CI likes that too, let's squash and merge |
in order to also allow building on JDK 13+, we also disambiguate some overloads and remove a no-longer-necesary scalaVersion override (at the build definition level) note that to use current sbt, we must also use current mima and exclude some spurious issues it reports this commit also includes some Dotty changes, contributed by Guillaume Martres. he describes them as follows: Fix stdlib compilation with dotty when using sbt 1.3 When we compile the standard library with dotty, we actually compile the scala-library and dotty-library sources together in one go since we can't in general reuse a dotty-library compiled with an old scala-library. There were two problems with the way this was done that were somehow masked so far (likely because of classpath pollution, but I don't know what changed in sbt 1.3 exactly): - Compiling the stdlib requires having all sources on the -sourcepath, but the sources from dotty-library itself were missing. - the files in scalaShadowing/ in dotty-library do need to be compiled, the comment above the exclusion was wrong. Additionally, I also removed the other exclusions done to files in dotty-library because they're no longer necessary. Co-authored-by: Guillaume Martres <smarter@ubuntu.com>
|
@retronym review/merge? |
|
I diffed the snapshot build of this PR vs that of the base commit. There are a few bytecode diffs that I don't understand. Looks like the behaviour of the optmizing backned is slightly different in the two runs. No idea if this is related to the SBT upgrade or if its a latent instability that we aren't catching. /cc @lrytz Oh I guess that's just the difference between a fully bootstrapped build (done on the merge commit) and a quick (done on this PR). No, I think its a genuine instablity in the 2.13.x optimizer. The first thing I'd try would be: diff --git a/src/compiler/scala/tools/nsc/backend/jvm/opt/InlinerHeuristics.scala b/src/compiler/scala/tools/nsc/backend/jvm/opt/InlinerHeuristics.scala
index 78d7c473bf..e7218cad98 100644
--- a/src/compiler/scala/tools/nsc/backend/jvm/opt/InlinerHeuristics.scala
+++ b/src/compiler/scala/tools/nsc/backend/jvm/opt/InlinerHeuristics.scala
@@ -134,7 +134,7 @@ abstract class InlinerHeuristics extends PerRunInit {
var size = method.instructions.size
val res = mutable.ListBuffer.empty[InlineRequest]
def include(kind: InlineReason, limit: Int): Unit = {
- var rs = byReason.getOrElse(kind, Nil)
+ var rs = byReason.getOrElse(kind, Nil).sorted(inliner.inlineRequestOrdering)
while (rs.nonEmpty && size < limit) {
val r = rs.head
rs = rs.tail |
|
This broke > scalac -Xprint:typer try/id.scala
[info] running (fork) scala.tools.nsc.Main -usejavacp -Xprint:typer try/id.scala
error: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.charAt(String.java:658)
at scala.reflect.io.ZipArchive$.splitPath(ZipArchive.scala:61)
at scala.reflect.io.ZipArchive$.scala$reflect$io$ZipArchive$$dirName(ZipArchive.scala:58)
at scala.reflect.io.ZipArchive.getDir(ZipArchive.scala:137)
at scala.reflect.io.FileZipArchive.root$lzycompute(ZipArchive.scala:204)
at scala.reflect.io.FileZipArchive.root(ZipArchive.scala:189)
at scala.reflect.io.FileZipArchive.allDirs$lzycompute(ZipArchive.scala:225)
at scala.reflect.io.FileZipArchive.allDirs(ZipArchive.scala:225)
at scala.tools.nsc.classpath.ZipArchiveFileLookup.findDirEntry(ZipArchiveFileLookup.scala:79)
at scala.tools.nsc.classpath.ZipArchiveFileLookup.list(ZipArchiveFileLookup.scala:66)
at scala.tools.nsc.classpath.ZipArchiveFileLookup.list$(ZipArchiveFileLookup.scala:65)
at scala.tools.nsc.classpath.ZipAndJarClassPathFactory$ZipArchiveClassPath.list(ZipAndJarFileLookupFactory.scala:57)
at scala.tools.nsc.classpath.AggregateClassPath.$anonfun$list$3(AggregateClassPath.scala:92)
at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:553)
at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:551)
at scala.collection.AbstractIterable.foreach(Iterable.scala:920)
at scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:88)
at scala.tools.nsc.util.ClassPath.list(ClassPath.scala:36)
at scala.tools.nsc.util.ClassPath.list$(ClassPath.scala:36)
at scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:31)
at scala.tools.nsc.symtab.SymbolLoaders$PackageLoader.doComplete(SymbolLoaders.scala:277)
at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.$anonfun$complete$2(SymbolLoaders.scala:229)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
at scala.reflect.internal.SymbolTable.informingProgress(SymbolTable.scala:85)
at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:227)
at scala.reflect.internal.Symbols$Symbol.completeInfo(Symbols.scala:1541)
at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1513)
at scala.reflect.internal.Mirrors$RootsBase.init(Mirrors.scala:262)
at scala.tools.nsc.Global.rootMirror$lzycompute(Global.scala:73)
at scala.tools.nsc.Global.rootMirror(Global.scala:71)
at scala.tools.nsc.Global.rootMirror(Global.scala:43)
at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:286)
at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:286)
at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1582)
at scala.tools.nsc.Global$Run.<init>(Global.scala:1205)
at scala.tools.nsc.Driver.doCompile(Driver.scala:47)
at scala.tools.nsc.MainClass.doCompile(Main.scala:30)
at scala.tools.nsc.Driver.process(Driver.scala:68)
at scala.tools.nsc.Driver.main(Driver.scala:82)
at scala.tools.nsc.Main.main(Main.scala) |
|
Upgrading the version of sbt used to build scalac broke in sbt's usage of scalac? I can't breathe. |
|
Not sure why or how but there's a ZipEntry with blank name. diff --git a/src/reflect/scala/reflect/io/ZipArchive.scala b/src/reflect/scala/reflect/io/ZipArchive.scala
index 985bde4cba..5af4bd6bed 100644
--- a/src/reflect/scala/reflect/io/ZipArchive.scala
+++ b/src/reflect/scala/reflect/io/ZipArchive.scala
@@ -124,6 +124,8 @@ abstract class ZipArchive(override val file: JFile, release: Option[String]) ext
}
protected def getDir(dirs: java.util.Map[String, DirEntry], entry: ZipEntry): DirEntry = {
+ println(s"""entry: "$entry" """)
+
def ensureDir(path: String): DirEntry =
dirs.get(path) match {
case null => |
|
I think this broke |
Oh, did you mean the |
|
|
This comes from a behaviour change in Before: After: |
|
/cc @eatkins |
|
Whoops. sbt/io#285. |
@dwijnand The problem is that the supershell buffers our "Are you sure [Y/N]" output line that we print to console in the I just found |
|
Workaround in #8652 |
|
@retronym @eatkins has a comprehensive fix for console and supershell interference - sbt/sbt#5319 |
It was reported in scala/scala#8525 that sbt does not correctly exclude the base directory when calling Path.allSubpaths. This ended up causing jar files to be created with an empty entry. The problem was in an incorrect equality check because the compiler did not flag for us that `PathFinder(base).globRecursive(filter).get()` returned `Seq[File]` but that we were filtering the results by comparing a `File` to a `Path`.
the sbt 1.3 upgrade is good for us to have, regardless of JDK version. but it does also allow building on JDK 13
as for the JDK 13+ specific part, we might still backslide since we aren't testing it in CI, but regardless, this is progress
this came up over at sbt/sbt#5093 (comment); a prospective contributor was trying to build Scala on JDK 13