Project configuration fails after migrating to 0.11.2+ #2844
Labels
Milestone
Comments
|
Thanks for this report. While I had a first glance, I recognized you're using some external plugins, and at least one ( We have a new CLI option I opened alexarchambault/mill-native-image#69 for it. |
|
|
|
Bumping diff --git a/build.sc b/build.sc
index 54f7eda..57610af 100644
--- a/build.sc
+++ b/build.sc
@@ -1,6 +1,6 @@
import $ivy.`de.tototec::de.tobiasroeser.mill.vcs.version::0.4.0`
-import $ivy.`io.github.alexarchambault.mill::mill-native-image::0.1.25`
-import $ivy.`io.github.alexarchambault.mill::mill-native-image-upload:0.1.19`
+import $ivy.`io.github.alexarchambault.mill::mill-native-image::0.1.26`
+import $ivy.`io.github.alexarchambault.mill::mill-native-image-upload:0.1.26`
import $ivy.`io.get-coursier::coursier-launcher:2.1.0-M2`
import de.tobiasroeser.mill.vcs.version._
@@ -112,7 +112,7 @@ trait ScalaJsCliNativeImage extends ScalaModule with NativeImage {
def graalVmVersion = "22.3.3"
def nativeImageGraalVmJvmId = s"graalvm-java17:$graalVmVersion"
def nativeImageName = "scala-js-ld"
- def moduleDeps() = Seq(
+ def moduleDeps = Seq(
cli
)
def compileIvyDeps = super.compileIvyDeps() ++ Seq(
@@ -353,7 +353,7 @@ object ci extends Module {
val path = os.Path(directory, os.pwd)
val launchers = os.list(path).filter(os.isFile(_)).map { path =>
- path.toNIO -> path.last
+ path -> path.last
}
val ghToken = Option(System.getenv("UPLOAD_GH_TOKEN")).getOrElse {
sys.error("UPLOAD_GH_TOKEN not set")Output: |
|
@lihaoyi Could you have a look? |
This was referenced Nov 10, 2023
|
@lefou although I did try to work around it in VirtusLab/scala-cli#2528, but eventually gave up with yet another failure (unclear if because of Looking forward to this issue getting fixed, regardless, we'll stay on |
|
I had some spare time and invested in narrowing down this issue. First, I made sure this is not related to external dependencies. I found an packaging issue in mill-native-image which is fixed in the meantime. So I opened PR VirtusLab/scala-js-cli#38. I also found some other issues which I addressed with PR VirtusLab/scala-js-cli#39. So, based on the branch/PR VirtusLab/scala-js-cli#39, I'm able to reproduce or mute the reported issue with a change of a single line: The failure with Mill 0.11.5diff --git a/.mill-version b/.mill-version
index 027934e..ce3191f 100644
--- a/.mill-version
+++ b/.mill-version
@@ -1 +1 @@
-0.11.1
\ No newline at end of file
+0.11.5-29-bc84d5The single-line change to remove the reported errordiff --git a/.mill-version b/.mill-version
index 027934e..ce3191f 100644
--- a/.mill-version
+++ b/.mill-version
@@ -1 +1 @@
-0.11.1
\ No newline at end of file
+0.11.5-29-bc84d5
diff --git a/build.sc b/build.sc
index 9df587f..1c7c722 100644
--- a/build.sc
+++ b/build.sc
@@ -55,7 +55,7 @@ trait Cli extends ScalaModule with ScalaJsCliPublishModule {
Parameters,
Preamble
}
- val cp = jarClassPath().map(_.path)
+ val cp = Seq.empty[os.Path]
val mainClass0 = mainClass().getOrElse(sys.error("No main class"))
val dest = T.ctx().dest / (if (isWin) "launcher.bat" else "launcher")Obviously the test fails, as I have just emptied the |
|
Here is a minimal reproducer: // /tmp/mill-2844/build.sc
import mill._
object foo extends Module {
def bar = T {
baz()
}
}
private def baz = T { "baz" }Removing |
lefou
added a commit
to lefou/scala-js-cli
that referenced
this issue
Nov 18, 2023
This not only makes them accessible from the CLI, it also fixes an issue with Mill 0.11.{2-5}.
See com-lihaoyi/mill#2844
|
Thanks for the minimization @lefou ! looks like it should be something to do with how |
|
Seems like when I look at the class GroupEvaluator.scala:98 namedTask: baz
GroupEvaluator.scala:99 namedTask.ctx.enclosingCls: class millbuild.build$
GroupEvaluator.scala:102 c: class millbuild.build$
GroupEvaluator.scala:103 c.getDeclaredMethods.map(_.getName): Array()
GroupEvaluator.scala:102 c: class millbuild.build
GroupEvaluator.scala:103 c.getDeclaredMethods.map(_.getName): Array(
"$deserializeLambda$",
"foo",
"foo$lzycompute$1",
"millbuild$build$$baz",
"$anonfun$baz$1",
"$anonfun$baz$3",
"$anonfun$baz$2"
)
|
|
A more minimal repro of this behavior appears to be the following Ammonite session, without Mill, where we demonstrate that the JVM name for @ trait Foo { private def bar = () } ; object Foo extends Foo
defined trait Foo
defined object Foo
@ classOf[Foo].getDeclaredMethods.map(_.getName)
res11: Array[String] = Array("$init$", "bar")
@ trait Foo { object qux{ bar }; private def bar = () } ; object Foo extends Foo
defined trait Foo
defined object Foo
@ classOf[Foo].getDeclaredMethods.map(_.getName)
res13: Array[String] = Array("$init$", "ammonite$$sess$cmd12$Foo$$bar$", "ammonite$$sess$cmd12$Foo$$bar", "qux") |
|
seems like removing the |
|
Should hopefully be fixed by https://github.com/com-lihaoyi/mill/pull/2883/files |
|
Additional to the proper fix, we should improve the error handling here. Now, that we know that |
Fixed in #2885 |
lihaoyi
added a commit
that referenced
this issue
Nov 19, 2023
…private nature (#2883) Fixes #2844 Adds an integration test to cover this edge case, a few other permutations of it that I could come up with, and other `private`-related behavior. I'm not sure if I managed to catch all different ways these methods can be mangled, but if I missed any we can discover/add them later. This new test fails if I remove any part of the code change in `GroupEvaluator.scala` I'm actually not sure if this should be an integration test or a unit test. * Technically this code path should be exercised in unit tests as well I think, and I think this failure mode should be triggerable. * But it might be affected by exactly how the `def`s are wrapped in nested `object`s/`trait`s/`class`es, which is something that unit tests do not do realistically. * Also, a unit test cannot exercise the failure code path when you try and specify a `private` target from the command, since it will simply not compile (being `private` and all), and AFAICT this is somewhere we're missing coverage (unrelated to this specific failure mode) So I went with integration test. Pull request: #2883
This was referenced Nov 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After migrating from 0.11.1 to any higher version, a project, that was working fine, fails on certain commands with an exception.
It happens in this repo: https://github.com/VirtusLab/scala-js-cli e.g. after doing ./mill -i 'tests.test'
Stack trace after setting the version to
0.11.2:It points to
main/eval/src/mill/eval/GroupEvaluator.scalaline 103, where aheadcall has been introduced in #2417.The text was updated successfully, but these errors were encountered: