Closed bohonghuang closed 3 years ago
I've run into the same issue with SBT and investigated it.
Unfortunately the message in the emacs log is quite confusing. What in fact happens is that the call to Metals fails. In .metals/metals.log
I found the following:
2021.09.08 17:13:20 ERROR No project associated with Uri(file:///<path-to-my-project-root>?id=root)
Sep 08, 2021 5:13:20 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
SEVERE: Internal error: scala.meta.internal.metals.MetalsBspException: BSP connection failed in the attempt to get: DebugSessionAddress. No project associated with Uri(file:///<path-to-my-project-root>?id=root)
java.util.concurrent.CompletionException: scala.meta.internal.metals.MetalsBspException: BSP connection failed in the attempt to get: DebugSessionAddress. No project associated with Uri(file:///<path-to-my-project-root>?id=root)
at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308)
at java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:647)
at java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:632)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977)
at scala.concurrent.java8.FuturesConvertersImpl$CF.apply(FutureConvertersImpl.scala:29)
at scala.concurrent.java8.FuturesConvertersImpl$CF.apply(FutureConvertersImpl.scala:26)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
at scala.concurrent.BatchingExecutor$Batch.processBatch$1(BatchingExecutor.scala:67)
at scala.concurrent.BatchingExecutor$Batch.$anonfun$run$1(BatchingExecutor.scala:82)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
at scala.concurrent.BatchingExecutor$Batch.run(BatchingExecutor.scala:59)
at scala.concurrent.Future$InternalCallbackExecutor$.unbatchedExecute(Future.scala:875)
at scala.concurrent.BatchingExecutor.execute(BatchingExecutor.scala:110)
at scala.concurrent.BatchingExecutor.execute$(BatchingExecutor.scala:107)
at scala.concurrent.Future$InternalCallbackExecutor$.execute(Future.scala:873)
at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:72)
at scala.concurrent.impl.Promise$DefaultPromise.$anonfun$tryComplete$1(Promise.scala:288)
at scala.concurrent.impl.Promise$DefaultPromise.$anonfun$tryComplete$1$adapted(Promise.scala:288)
at scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala:288)
at scala.concurrent.Promise.complete(Promise.scala:53)
at scala.concurrent.Promise.complete$(Promise.scala:52)
at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:187)
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: scala.meta.internal.metals.MetalsBspException: BSP connection failed in the attempt to get: DebugSessionAddress. No project associated with Uri(file:///<path-to-my-project-root>?id=root)
at scala.meta.internal.metals.BuildServerConnection$$anonfun$1.applyOrElse(BuildServerConnection.scala:237)
at scala.meta.internal.metals.BuildServerConnection$$anonfun$1.applyOrElse(BuildServerConnection.scala:229)
at scala.concurrent.Future.$anonfun$recoverWith$1(Future.scala:417)
at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:41)
... 4 more
After additional digging I realized that the failure occurs in Bloop and not Metals (relevant code line)
What Bloop is trying to do there is to extract a project name with the given ID (here).
From Metals' logs we can see that the passed ID is root
, so it's trying to fetch a module with this ID and fails.
Long story short lsp-metals
has the root
ID hardcoded (here) which means that each project is expected to have a root module and not just submodules.
In my build.sbt
I was missing the following:
lazy val root = (project in file("."))
.aggregate(<the_list_of_my_submodules>)
After introducing above lines to my build.sbt
the dap-debug
with the Scala Attach
template worked as expected.
Unfortunately I don't know how to work this around in Gradle.
I wish this behavior was at least documented somewhere. Ideally this should be fixed.
@HuangBoHong I tried your example and noticed that if I rename the core
module to root
, the Scala Attach
template works as expected. Perhaps you can find a way to create an umbrella root
project in Gradle similarly to how I did this in SBT (see my previous comment).
I've created a PR (https://github.com/emacs-lsp/lsp-metals/pull/59) which makes the project ID configurable. If it gets merged then the original Gradle issue can be addressed using the following config:
(dap-register-debug-template
"Scala Attach Core"
(list :type "scala"
:request "attach"
:name "Scala Attach Core"
:buildTarget "core"
:hostName "localhost"
:port 5005))
Note that the buildTarget
is set to the module name from attached sources.
UPD: updated the above snippet based on changes in the PR.
@HuangBoHong I tried your example and noticed that if I rename the
core
module toroot
, theScala Attach
template works as expected. Perhaps you can find a way to create an umbrellaroot
project in Gradle similarly to how I did this in SBT (see my previous comment).
I did as you instructed and it works as expected. Thanks!
Describe the bug Unable to run gradle project via dap-debug, while lsp-lens functions well.
To Reproduce A minimal project to reproduce the issue: scala3gradle.zip
Logs