SemanticDB not found when using mill-bsp

[asarkar]

I'm an IntelliJ defector due to the fact it refuses to recognize Scala 3 new syntax with Mill. My project is pretty basic, and the structure is shown below.

The build.sc is given below.

import mill._, scalalib._, scalafmt._

trait AdvancedScalaModule extends ScalaModule with ScalafmtModule {
  val baseDir = build.millSourcePath
  def scalaVersion = "3.3.1"
  def scalatestVersion = "3.2.17"
  def scalacheckVersion = "3.2.17.0"
  override def scalacOptions: T[Seq[String]] = Seq(
    "-encoding", "utf8",
    "-feature",
    "-Werror",
    "-explain",
    "-deprecation",
    "-unchecked",
    // Require then and do in control expressions
    "-new-syntax",
    "-rewrite",
    "-source", "future",
    // Tell Metals the location of SemanticDB
    // s"-Xplugin:semanticdb -sourceroot:$baseDir"
  )
}

object exercises extends AdvancedScalaModule {
  object test extends ScalaTests with TestModule.ScalaTest {
    // // use `::` for scala deps, `:` for java deps
    override def ivyDeps = Agg(
      ivy"org.scalactic::scalactic:$scalatestVersion",
      ivy"org.scalatest::scalatest:$scalatestVersion",
      ivy"org.scalatestplus::scalacheck-1-17:$scalacheckVersion"
    )
  }
}

object lectures extends AdvancedScalaModule

Notice the -Xplugin:semanticdb -sourceroot:$baseDir compiler option that is commented out. This is recommended by Metals Doctor (see screenshot below), but when uncommented, produces an error in the Metals logs to the effect of "plugin not found".

This problem is documented in the Mill documentation, but I couldn't find any open ticket corresponding to this problem.

As of writing this, Metals 0.11.8 is the latest available version, which is not able to detect the fact, that Mill is already providing SemanticDB data. As a consequence, it reports missing SemanticDB data, although some SemanticDB-based features are already working.

Expected behaviour:

No error in the logs or in the Metals Doctor report, and all functionality working as expected.

Operating system: Mac OS X

Java version: 17.0.9

Editor/extension: Visual Studio Code v1.84.2

Metals version: 1.1.0

Extra context or search terms:

N/A.

Workspace information:

• Scala versions: 3.3.1; 2.13.12
• Build tools: 0. mill
• Build servers:
  0. mill-bsp v0.11.6
• All build tools in workspace: Mill

[tgodzik]

Thanks for reporting! The warning is a false positive one, you can ignore it. Next Metals release should not show it. Thanks to mill contributors, semanticdb is properly provided for Metals without the need to specify any additional options.

[asarkar]

@tgodzik So, you’re saying the note in the Mill docs is no longer correct?

As of writing this, Metals 0.11.8 is the latest available version, which is not able to detect the fact, that Mill is already providing SemanticDB data.

[asarkar]

On an unrelated note, Metals doesn’t seem to be able to find the tests. Can you advise if the project structure shown above is known to it, and how to run a Scalatest class/test?

[tgodzik]

Tests do not currently work with Mill BSP unfortunately.

[tgodzik]

@tgodzik So, you’re saying the note in the Mill docs is no longer correct?

As of writing this, Metals 0.11.8 is the latest available version, which is not able to detect the fact, that Mill is already providing SemanticDB data.

Yes, we should update that.

[asarkar]

Tests do not currently work with Mill BSP unfortunately.

Is there a ticket for it? If not, I can open one?

~Regarding Mill docs, I'll open a ticket on their gitHub Repo to update the docs.~ https://github.com/com-lihaoyi/mill/issues/2906

[lefou]

Tests do not currently work with Mill BSP unfortunately.

I think, this is because Metals is not using the dedicated TestProvider capability (which Mill implements) but the DebugProvider capability (which Mill doesn't implement) to run tests. I'm aware, that using the DebugProvider gives Metals more options in terms of selective test execution, but effectively for Mill it just means tests don't work.

Also, we (Mill contributors) postponed the implementation of DebugProvider capability in Mill as IJ IDEA does not need it and Metals was supposed to also not need it eventually, as the plan was to start the DAP (debug adapter protocol) in Metals directly. But it seems to me, this no longer holds true, as I can't detect any work in that direction. @tgodzik Maybe, you could clarify the official Metals view point. Any outcomes is better that the status quo in which all parties (users as well as contributors to Mill and Metals) wait on each other.

[lefou]

Tests do not currently work with Mill BSP unfortunately.

Is there a ticket for it? If not, I can open one?

Not directly about test runners, but as Metals use the DebugProvider capability to run tests, this is the feature request in Mill:

• https://github.com/com-lihaoyi/mill/issues/2225

[asarkar]

@lefou Although tangential to this ticket, IntelliJ didn’t recognize the Scala 3 new syntax (if-then, while-do etc.), so, the user experience with Mill using any of the two IDEs is really subpar. As a user, I just want to be able to get basic stuff done, without red underlines all over the code and tests not recognized.

[lefou]

@lefou Although tangential to this ticket, IntelliJ didn’t recognize the Scala 3 new syntax (if-then, while-do etc.), so, the user experience with Mill using any of the two IDEs is really subpar. As a user, I just want to be able to get basic stuff done, without red underlines all over the code and tests not recognized.

I guess, we all agree on that part. Personally, I can't use Metals for most of my projects due to their polyglot nature. But from what I've heard, Metals has the better support for Scala 3 features. Running tests from the IDE, which you can also do from the CLI, is IMHO the smaller showstopper.

[tgodzik]

But it seems to me, this no longer holds true, as I can't detect any work in that direction. @tgodzik Maybe, you could clarify the official Metals view point. Any outcomes is better that the status quo in which all parties (users as well as contributors to Mill and Metals) wait on each other.

Yes, we do have a plan like that, but we were lacking time to do it. Let me open up an issue. I didn't concentrate on it, because you are able to do it via Bloop if you really needed it. However, it makes much more sense for it to be directly in Metals.

[tgodzik]

We can discuss it further in https://github.com/scalameta/metals/issues/5928

[lefou]

~Does that also means, Metals will be able to run tests or will it still not work unless Mill BSP implements DebugProvider capability?~

Let's continue in #5928.

[tgodzik]

The exact issues will be fixed in the new release. We can focus on the moving scala-debug-adapter usage in MEtals in the other ticket