BSP 'buildTarget/scalacOptions` classpath doesn't contain classses from this build target about mill HOT 6 CLOSED

Without looking up the sources and the BSP spec I don't understand the issue you describe and what exactly is missing. Can you elaborate?

from mill.

For a simple project similar to https://github.com/com-lihaoyi/mill-scala-hello.g8, classpath for the build target looks like this

"file://.../scala-hello-world/scalaHelloWorld/compile-resources",
"file://.../Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.3.1/scala3-library_3-3.3.1.jar",
"file://.../Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.10/scala-library-2.13.10.jar"

But classpath in buildTarget/jvmRunEnvironment for the same build target contains also

"file://.../scala-hello-world/scalaHelloWorld/resources",
"file://.../scala-hello-world/out/scalaHelloWorld/compile.dest/classes"

Without the last line, presentation compiler created in metals doesn't have information from other classes in the same build target. Adding "file://.../scala-hello-world/out/scalaHelloWorld/compile.dest/classes" also to scalacOptions response solves the problem.

We could probably work around it in Metals, but maybe it's an easy fix here?

from mill.

For a simple project similar to https://github.com/com-lihaoyi/mill-scala-hello.g8, classpath for the build target looks like this

"file://.../scala-hello-world/scalaHelloWorld/compile-resources",
"file://.../Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.3.1/scala3-library_3-3.3.1.jar",
"file://.../Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.10/scala-library-2.13.10.jar"

This is the classpath, which is used for compiling.

But classpath in buildTarget/jvmRunEnvironment for the same build target contains also

"file://.../scala-hello-world/scalaHelloWorld/resources",
"file://.../scala-hello-world/out/scalaHelloWorld/compile.dest/classes"

This is the runClasspath, which also contains the result of the compilation.

For obvious reasons, we can't add the result of the compilation as an input to the compilation.

scalacOptions is also an input to the compilation, so it also can't contain the output of the same compilation.

I don't know how the presentation compiler works, but as the compiler typically sees the source files of the current module, this should be enough for it to have the whole picture. Using the readily compiled class files as input in the compiler to make completions and stuff work doesn't make much sense to me. Something is missing here. At least, I don't get it.

from mill.

So it looks like in Bloop and sbt it's put on the classpath when being sent via BSP while not being used for compilation. We can work around it in Metals as you are right in terms of the actual specification.

from mill.

I think we should review the spec and make it clear what's expected to be in the respective requests. I think my interpretation outlined above should be correct, but maybe I'm wrong. returning different values in the same request as you said is done by bloop and sbt is most likely incorrect and should be fixed there and not worked around in Metals (except for compatibility with older versions). Unless I misunderstood. I'm going to close this issue for now, as I have no idea what I can do about it.

from mill.

I think it's fine as is. We can have a workaround, it's not a big deal. You are right that Mill is following the spec here.

from mill.