Alternative way of detecting SemanticDB

[ckipp01]

Outline

So recently @lefou merged in much better SemanticDB support for Mill when using Mill as a build server. This means Metals users can now use Mill as a BSP server (in the upcoming release) without any manual changes needed to their build. SemanticDB related features work:

The one issue though that you'll hit on is that we fully rely on scanning the scalacOptions to see if SemanticDB is enabled:

Here for Scala

metals/metals/src/main/scala/scala/meta/internal/metals/MetalsEnrichments.scala

Lines 873 to 884 in 18192e3

	def isSemanticdbEnabled(scalaVersion: String): Boolean = {
	if (ScalaVersions.isScala3Version(scalaVersion)) {
	item.getOptions.asScala.exists { opt =>
	opt == "-Ysemanticdb" || opt == "-Xsemanticdb"
	}
	} else {
	item.getOptions.asScala.exists { opt =>
	opt.startsWith("-Xplugin:") && opt
	.contains("semanticdb-scalac")
	}
	}
	}

Here for Java

metals/metals/src/main/scala/scala/meta/internal/metals/MetalsEnrichments.scala

Lines 809 to 813 in 18192e3

	def isSemanticdbEnabled: Boolean = {
	item.getOptions.asScala.exists { opt =>
	opt.startsWith("-Xplugin:semanticdb")
	}
	}

Mill takes a bit different approach than the other build servers to in that there's a separate task that creates the SemanticDB only when a tool like Metals is detected. Since it's a separate task you won't actually see the thing we look for in the scalacOptions, but you sill find SemanticDB in the classDirectory.

"classDirectory": "file:///Users/ckipp/Documents/scala-workspace/minimal/out/minimal/compiledClassesAndSemanticDbFiles.dest"

Given this situation we don't want to tell the user that there is no SemanticDB when there is. So how should we handle this situation?

Possible Solutions

1. We detect that mill-bsp is being used and if it's a new enough version we just assume that it is?
2. We detect that mill-bsp is being used and then doublecheck that the classDirectory name contains SemanticDb?
3. We use data during the initialize and introduce some semanticDbOverride: true or something like that which notifies the client that SemanticDB is being produced even though we don't see it reflected in the scalacOptions?
4. Something else?

Before digging into this I'm curious if anyone has any thoughts on the above or potential solutions for this.

[tgodzik]

I think 1. should be enough together with maybe semanticdb being reported as missing similar to compilation status? However, if we plan on more tools working with that approach, maybe sending some data to Metals with the info where semanticdb might be located would probably better.

[lefou]

Mill detects the fact that a BSP client wants SemanticDB data at initialization time. We parse the extra data and read the requested SemanticDB version. Unfortunately, the InitializeBuildResult from the BSP protocol has no back channel, where we can push some details to the client.

[ckipp01]

I created #4295 to partially address this. This will get rid of the warnings for mill-bsp users about semanticdb and sourceroot not being set for Scala targets but they will still get a warning about Java support.