Unhandled exception with relative path #6850
Description
Hello,
We are facing a boggling issue when bumping from mill 1.0.0-RC1 to 1.1.X on a Scala3 project. To start with a tentatively short description, we see:
1867] An unhandled exception was thrown in the compiler.
1867] Please file a crash report here:
1867] https://github.com/scala/scala3/issues/new/choose
1867] For non-enriched exceptions, compile with -Xno-enrich-error-messages.
1867]
1867]
1867] while compiling: <no file>
1867] during phase: parser
1867] mode: Mode()
1867] library version: version 3.8.1
1867] compiler version: version 3.8.1
1867] settings: -Wunused List(imports, imports) -classpath /home/runner/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/3.8.1/scala-library-3.8.1.jar:/home/runner/.cache/coursier/v1/https/repo1.maven.org/maven2/com/lihaoyi/fastparse_3/3.1.1/fastparse_3-3.1.1.jar:/home/runner/.cache/coursier/v1/https/repo1.maven.org/maven2/com/lihaoyi/sourcecode_3/0.4.0/sourcecode_3-0.4.0.jar:/home/runner/.cache/coursier/v1/https/repo1.maven.org/maven2/com/lihaoyi/geny_3/1.1.0/geny_3-1.1.0.jar:/home/runner/work/scair/scair/utils/compile-resources:/home/runner/work/scair/scair/out/utils/scoverage/compile.dest/classes:/home/runner/work/scair/scair/core/compile-resources:/home/runner/work/scair/scair/out/core/scoverage/compile.dest/classes -color never -coverage-out /home/runner/work/scair/scair/out/core/scoverage/data.dest -d /home/runner/work/scair/scair/out/core/scoverage/compile.dest/classes -explain true -sourceroot /home/runner/work/scair/scair
1867]
Error: 1867] [error] ## Exception when compiling 43 sources to /home/runner/work/scair/scair/out/core/scoverage/compile.dest/classes
1867] java.lang.IllegalArgumentException: requirement failed: core/src/clair/Macros.scala is not an absolute path
1867] scala.Predef$.require(Predef.scala:394)
1867] os.Path.<init>(Path.scala:574)
1867] os.Path$.apply(Path.scala:497)
1867] mill.javalib.zinc.TransformingReporter$.dottyStyleMessage(TransformingReporter.scala:85)
1867] mill.javalib.zinc.TransformingReporter$.mill$javalib$zinc$TransformingReporter$$$transformProblem(TransformingReporter.scala:40)
1867] mill.javalib.zinc.TransformingReporter.log(TransformingReporter.scala:15)
1867] mill.javalib.zinc.TransformingReporter.log$(TransformingReporter.scala:3)
[...] Long stacktrace elided!
Looking in the related files, this happens at:
https://github.com/com-lihaoyi/mill/blob/1.1.2/libs/javalib/worker/src/mill/javalib/zinc/TransformingReporter.scala#L85.
Where an absolute path is expected.
EDIT: The following might be more about me going in a rabbit hole assuming the absolute path expectation is important. If that's the case, here's a PR attempting a good-enough fix:
Otherwise, more details below:
I compiled some local changes to Mill 1.1.2 to hack through and get it to not crash on a relative path, and could see that this is only a compilation warning from dotty, that this reporting code did not handle well; leading to this complete error-out with no useful information, so I figured this might be something to fix on Mill's side either way?
For a bit more details, this seems to happen in specific scenarios only, as it only triggers when compiling with scoverage in our project - "normal" compilation happening just fine. So I think it might be a tricky corner-case of the dotty-mill integration? I'm really not familiar with the details there!
The complete CI run from which the above output is taken can be found there in case it helps:
https://github.com/edin-dal/scair/actions/runs/22146364124/job/64024590007
I tried but could not really come up with a MFE as well, including some inline defs and macro usage, which seem to play a role in ending up with a relative path passed to this function 🤔 I feel it might be a perfect cocktails of those, circular dependencies and more bad patterns on our end, but again, feels like something that could be handled better by this reporting code I believe?
One thing I noticed while hacking through Mill to let the warnings display, is that somehow all erroneous cases were of the "the type test for ...[...] cannot be checked at runtime because its type arguments can't be determined from ..." type. (But some warnings of this type were also passed with an absolute path). In case that could help figure anything out?
I was not sure how to phrase that all or how much context to include, I hope this issue makes a bit of sense, and I am happy to provide more details or context anytime, thank you! 🙂