emacs-lsp / lsp-metals

lsp-mode :heart: metals
https://emacs-lsp.github.io/lsp-metals
GNU General Public License v3.0
58 stars 33 forks source link

dap-debug not working in gradle project #57

Closed bohonghuang closed 3 years ago

bohonghuang commented 3 years ago

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

LSP :: `workspace/executeCommand' with `debug-adapter-start' failed.

(error "Internal error.")
lsp-metals-populate-config: Wrong type argument: hash-table-p, #("LSP :: `workspace/executeCommand' with `debug-adapter-start' failed.
izeigerman commented 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.

izeigerman commented 3 years ago

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

izeigerman commented 3 years ago

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.

bohonghuang commented 3 years ago

@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 did as you instructed and it works as expected. Thanks!