Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
scarf005 opened this issue Sep 18, 2024 · 6 comments
Open

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

scarf005 opened this issue Sep 18, 2024 · 6 comments
Labels
Bloop Issues tied with Bloop integration. bug Something isn't working needs reproduction

Comments

@scarf005
Copy link

scarf005 commented Sep 18, 2024

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 scarf005 added the bug Something isn't working label Sep 18, 2024
@Gedochao
Copy link
Contributor

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
Copy link
Contributor

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

@scarf005
Copy link
Author

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
Copy link
Contributor

Gedochao commented Sep 19, 2024

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
Copy link
Author

scarf005 commented Sep 19, 2024

  • 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

@lbialy
Copy link

lbialy commented Sep 19, 2024

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

@Gedochao Gedochao added the Bloop Issues tied with Bloop integration. label Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bloop Issues tied with Bloop integration. bug Something isn't working needs reproduction
Projects
None yet
Development

No branches or pull requests

3 participants