scala-cli icon indicating copy to clipboard operation
scala-cli copied to clipboard

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

Open scarf005 opened this issue 1 year ago • 6 comments

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.

scarf005 avatar Sep 18 '24 14:09 scarf005

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 avatar Sep 19 '24 06:09 Gedochao

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

Gedochao avatar Sep 19 '24 06:09 Gedochao

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.

scarf005 avatar Sep 19 '24 07:09 scarf005

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

Gedochao avatar Sep 19 '24 07:09 Gedochao

  • I was able to make it work with --server=false flag.
  • Running scala-cli --power bloop exit stopped the issue from happening again.

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

scarf005 avatar Sep 19 '24 12:09 scarf005

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).

lbialy avatar Sep 19 '24 12:09 lbialy

I experience this every day since a few weeks on ubuntu. Always happens when metals is running on the same project. I use metals+vim. To reproduce:

  1. open a scala file in vim
  2. try to build the same project in a terminal window (or terminal bugger) with scala-cli

wasowski avatar Nov 12 '24 17:11 wasowski

This exception is something that should not happen when invoking the compiler normally and it is. I raised an issue https://github.com/scala/scala3/issues/21947 since we don't really have enough information.

Also, I realized this might be an issue related to https://github.com/scala/bug/issues/13045

tgodzik avatar Nov 14 '24 11:11 tgodzik