mill
mill copied to clipboard
com-lihaoyi
Make Mill BSP server a `debugProvider`.
This is a feature request related to using Mill as a BSP server. Currently Metals is a runProvider and testProvider, but not a debugProvider as you can see in the initialize response here:
[Trace - 11:12:05 am] Received response 'build/initialize - (1)' in 611ms
Result: {
"displayName": "mill-bsp",
"version": "0.10.10",
"bspVersion": "2.0.0",
"capabilities": {
"compileProvider": {
"languageIds": [
"java",
"scala"
]
},
"testProvider": {
"languageIds": [
"java",
"scala"
]
},
"runProvider": {
"languageIds": [
"java",
"scala"
]
},
"debugProvider": {
"languageIds": []
},
"inverseSourcesProvider": true,
"dependencySourcesProvider": true,
"dependencyModulesProvider": true,
"resourcesProvider": true,
"outputPathsProvider": true,
"buildTargetChangedProvider": false,
"jvmRunEnvironmentProvider": true,
"jvmTestEnvironmentProvider": true,
"canReload": true
}
}
This means that tools like Metals can't offer debugging in the editor for you Mill project.
Potential solutions
Probably an integration with https://github.com/scalacenter/scala-debug-adapter.
Using scala-debug-adapter is probably the way to go. But we need a Scala 2.13 version of it, which is currently not released.
- See https://github.com/scalacenter/scala-debug-adapter/pull/363
After some conversations on the Scala Tooling Summit, I learned that Metals plans to add support to start the Debug Adapter directly, as all information about the buildTarget is already present. Hence, we don't need to implement the debugProvider capability.
I haven't found any evidence, that Metals is indeed providing debug adapter support directly, so I think this issue might be still valid and any help would be appreciated.
For what it's worth, Mill doesn't seem to need to implement debugProvider, since this ticket at Metals has been moved to In Progress:
- https://github.com/scalameta/metals/issues/5928
