metals editor client - stale bloop error instead of publishDiagnostics

[Sciss]

Hi there, I'm trying to revive my attempt at building an editor with metals integration. When editing, I am saving a temporary .scala file from which I then get diagnostics. I run into this problem: Say the editor contents is

object HelloWorld:
  def main(args: Array[String]): Unit =
    println("Hello World!")
    println(s"argc ${args.length}")
    for a <- args do println(s"  $a")

and I delete the last closing quotation marks:

object HelloWorld:
  def main(args: Array[String]): Unit =
    println("Hello World!")
    println(s"argc ${args.length}")
    for a <- args do println(s"  $a)

Now instead of getting diagnostics with the corresponding error, I am seeing empty diagnostics followed by a log message about bloop:

[DEBUG] [08/04/2023 23:34:44.798] [pool-1-thread-1] [akka://ScalaParser/user/compiler] 2023.08.04 23:34:44 INFO  compiling dotterweide11794721117469590605-tmp (1 scala source)
publishDiagnostics for file:///tmp/dotterweide11794721117469590605.tmp/src/main/scala/dotterweide.scala
>>>
<<<
[DEBUG] [08/04/2023 23:34:44.813] [pool-1-thread-1] [akka://ScalaParser/user/compiler] 2023.08.04 23:34:44 INFO  file:///tmp/dotterweide11794721117469590605.tmp/src/main/scala/dotterweide.scala:5:36: stale bloop error: unclosed string literal
    for a <- args do println(s"  $a)
                                   ^
[DEBUG] [08/04/2023 23:34:44.840] [pool-1-thread-1] [akka://ScalaParser/user/compiler] 2023.08.04 23:34:44 INFO  time: compiled dotterweide11794721117469590605-tmp in 42ms

What is going wrong here? Why do I first get empty diagnostics, then the logger says "stale bloop error" instead of getting that compile error through LSP?

[tgodzik]

Och, I think I know the issue here or at least partly. In

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

Line 288 in a829a6a

d.getRange.toMeta(snapshot).foreach { pos =>

we use edit distance to calculate if any tokens moved to adjust the diagnostic position, but this is problematic with code that doesn't tokenize, which is the case with missing "".

We should probably improve that within scalaemta and make tokenization more foolproof or at least account for it in Metals itself. I will take a quick look at that.

[tgodzik]

Dealing with that here #5530

You should still get correct diagnostics from Metals about the tokenization issue.

[Sciss]

I see, thank you.