Skip to content

Fix scalac plugin paths in BSP options response#23564

Open
alexanderheldt wants to merge 1 commit into
pantsbuild:mainfrom
alexanderheldt:fix-bsp-scalac-plugin-paths
Open

Fix scalac plugin paths in BSP options response#23564
alexanderheldt wants to merge 1 commit into
pantsbuild:mainfrom
alexanderheldt:fix-bsp-scalac-plugin-paths

Conversation

@alexanderheldt

Copy link
Copy Markdown
Contributor

handle_bsp_scalac_options_request put scalac plugin jars under .pants.d/bsp/, but emits the -Xplugin: options relative to the build root:

-Xplugin:jvm/resolves/scala213/plugins/org.scalameta_semanticdb-scalac_2.13.18_4.17.2.jar

while the jars actually are in .pants.d/bsp/jvm/resolves/scala213/plugins, so there is a mismatch here which causes BSP to not find e.g. semanticdb which causes metals to log

java.nio.file.NoSuchFileException: /home/alex/code/work/backend/jvm/resolves/scala213/plugins/org.scalameta_semanticdb-scalac_2.13.18_4.17.2.jar
	at scala.meta.internal.metals.CompilerPlugins.$anonfun$isSupportedPlugin$1(CompilerPlugins.scala:64)

I tested this locally with my pants fork and the fix ensures semanticdb is loaded correctly when using metals.

LLM usage note: Had an LLM write the docs summary for me

The BSP buildTarget/scalacOptions handler emitted -Xplugin: arguments
using a digest-relative prefix, producing relative paths that BSP
clients could not resolve. The plugin jars are materialized under
.pants.d/bsp in the workspace, so emit absolute paths there instead,
matching the classpath and class_directory fields in the same response.
@alexanderheldt
alexanderheldt force-pushed the fix-bsp-scalac-plugin-paths branch from 5bf9c1e to 4daf37e Compare July 23, 2026 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant