VirtusLab / scala-cli

Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!)
https://scala-cli.virtuslab.org
Apache License 2.0
551 stars 129 forks source link

assertion failed: asTerm called on not-a-Term val <none> #3184

Open scarf005 opened 1 month ago

scarf005 commented 1 month ago

Version(s) Scala CLI version: 1.5.0 Scala version (default): 3.5.0 OS: fedora 40 (kinoite)

Describe the bug

scala-cli suddenly fails to run simple (or any) scripts.

To Reproduce

// hello.scala
@main def main() = println("Hello World")
scarf@fedora ~/r/aoc-scala (main) [1]> scala-cli run hello.scala 
Compiling project (Scala 3.5.0, JVM (17))
Error compiling project (Scala 3.5.0, JVM (17))
Error: Unexpected error when compiling aoc-scala_bde03bda35-5224438d5a: java.lang.AssertionError: assertion failed: asTerm called on not-a-Term val <none>
        at scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:8)
        at dotty.tools.dotc.core.Symbols$Symbol.asTerm(Symbols.scala:186)
        at dotty.tools.dotc.core.Definitions.ObjectClass(Definitions.scala:325)
        at dotty.tools.dotc.core.Definitions.ObjectType(Definitions.scala:329)
        at dotty.tools.dotc.core.Definitions.AnyRefAlias(Definitions.scala:428)
        at dotty.tools.dotc.core.Definitions.syntheticScalaClasses(Definitions.scala:2163)
        at dotty.tools.dotc.core.Definitions.syntheticCoreClasses(Definitions.scala:2176)
        at dotty.tools.dotc.core.Definitions.init(Definitions.scala:2192)
        at dotty.tools.dotc.core.Contexts$ContextBase.initialize(Contexts.scala:921)
        at dotty.tools.dotc.core.Contexts$Context.initialize(Contexts.scala:544)
        at dotty.tools.dotc.Run.rootContext(Run.scala:503)
        at dotty.tools.dotc.Run.<init>(Run.scala:524)
        at dotty.tools.dotc.Compiler.newRun(Compiler.scala:174)
        at dotty.tools.dotc.Driver.doCompile(Driver.scala:35)
        at dotty.tools.xsbt.CompilerBridgeDriver.run(CompilerBridgeDriver.java:141)
        at dotty.tools.xsbt.CompilerBridge.run(CompilerBridge.java:22)
        at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:91)
        at sbt.internal.inc.bloop.internal.BloopHighLevelCompiler.compileSources$1(BloopHighLevelCompiler.scala:133)
        at sbt.internal.inc.bloop.internal.BloopHighLevelCompiler.$anonfun$compile$7(BloopHighLevelCompiler.scala:159)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
        at sbt.internal.inc.bloop.internal.BloopHighLevelCompiler.$anonfun$compile$1(BloopHighLevelCompiler.scala:71)
        at bloop.tracing.NoopTracer$.trace(BraveTracer.scala:53)
        at sbt.internal.inc.bloop.internal.BloopHighLevelCompiler.timed$1(BloopHighLevelCompiler.scala:70)
        at sbt.internal.inc.bloop.internal.BloopHighLevelCompiler.$anonfun$compile$6(BloopHighLevelCompiler.scala:159)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
        at monix.eval.internal.TaskRunLoop$.startFull(TaskRunLoop.scala:81)
        at monix.eval.internal.TaskRestartCallback.syncOnSuccess(TaskRestartCallback.scala:101)
        at monix.eval.internal.TaskRestartCallback.onSuccess(TaskRestartCallback.scala:74)
        at monix.eval.internal.TaskExecuteOn$AsyncRegister$$anon$1.run(TaskExecuteOn.scala:71)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1726)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1717)
        at java.base/java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(ForkJoinTask.java:1641)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1489)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2071)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2033)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

Compilation failed

Expected behaviour A clear and concise description of what you expected to happen.

scala-cli works.

Additional Info

scarf@fedora ~/r/aoc-scala (main) [1]> scala-cli clean --help
Usage: scala-cli clean [options]
Clean the workspace.

You are currently viewing the basic help for the clean sub-command. You can view the full help by running: 
   scala-cli clean --help-full
For detailed documentation refer to our website: https://scala-cli.virtuslab.org/docs/commands/clean

Launcher options:
  --power  Allows to use restricted & experimental features
scarf@fedora ~/r/aoc-scala (main)> scala-cli clean 
scala.build.errors.InputsException: No inputs provided (expected files with .scala, .sc, .java or .md extensions, and / or directories).
scarf@fedora ~/r/aoc-sc

at first i thought it was due to corrupt cache, and tried clean but it fails with mysterious errors (usage does not state it requires input files)

i searched for similar issues like #2117 and #2241, but they seems to be unrelated in terms of used scripts.

Gedochao commented 1 month ago

at first i thought it was due to corrupt cache, and tried clean but it fails with mysterious errors (usage does not state it requires input files)

It does require input files. We can tweak the help message, I suppose.

scala-cli suddenly fails to run simple (or any) scripts.

Any hints on what could have caused it? There's not much context to go on. I can't seem to reproduce this, even on a linux machine.

Gedochao commented 1 month ago

Also, does passing the --server=false option help?

scarf005 commented 1 month ago

Any hints on what could have caused it? There's not much context to go on.

It happened after I opened the project on vscode+metals. I'd love to provide more context but unsure which file to provide; maybe $HOME/.cache/scala-cli? erasing dotfiles like .bsp and .bloop didn't help

Also, does passing the --server=false option help?

will try after I get home.

Gedochao commented 1 month ago

Running with -v -v -v might also provide us with some hint in the logs.

If --server=false helps, it'd mean Bloop (the build server) is the culprit... in which case it may also make sense to restart it with:

scala-cli --power bloop exit
scarf005 commented 1 month ago

thanks for the help. here's the output of scala-cli run -v -v -v hello.scala for reference: output.log

lbialy commented 1 month ago

Sounds like a race condition in bloop. I see stuff like that pretty often given my workflow is based on using both metals and scala-cli simultaneously (e.g., I finish writing code in vscode, run scala-cli compile in terminal).