Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BSP: Incorrect range end position in problem reporter #1011

Closed
lefou opened this issue Nov 26, 2020 · 4 comments
Closed

BSP: Incorrect range end position in problem reporter #1011

lefou opened this issue Nov 26, 2020 · 4 comments

Comments

@lefou
Copy link
Member

lefou commented Nov 26, 2020

Originally posted by @ckipp01 in #999 (comment)

Screenshot 2020-11-24 at 18 02 37

One other thing that I do notice though is that the diagnostic from Mill is as follows:

"diagnostics": [
    {
      "range": {
        "start": {
          "line": 8,
          "character": 15
        },
        "end": {
          "line": 8,
          "character": 15
        }
      },
      "severity": 1,
      "source": "compiler from mill",
      "message": "type mismatch;\n found   : String(\"hi\")\n required: Int"
    }
  ],

Whereas both with sbt and with Bloop it's:

"diagnostics": [
    {
      "range": {
        "start": {
          "line": 8,
          "character": 15
        },
        "end": {
          "line": 8,
          "character": 19
        }
      },
      "severity": 1,
      "source": "sbt",
      "message": "type mismatch;\n found   : String(\"hi\")\n required: Int"
    }
  ]

It still seems to work fine (I think there is some magic on the LSP client side) to maybe highlight the full symbol, but it'd be better to correctly capture the entire range and not return 15 for both start character and end character.

If it helps at all, here is the code sbt uses to get the range from the Problem.

https://github.com/sbt/sbt/blob/13b09bcd8fa0fde86aa4f4f8d7089fcb18e345c6/main/src/main/scala/sbt/internal/server/BuildServerReporter.scala#L133-L159

@ckipp01
Copy link
Contributor

ckipp01 commented Jun 3, 2021

So I didn't really realize this at the time, but this actually shouldn't be an issue for Metals. Metals actually takes that diagnostic and expands the range to the token in order to keep diagnostics alongside sytnax errors when you type. So when you look at the bsp.trace.log file it may look off, but in the lsp.trace.log file, it's right. This popped up during a conversation on matrix about IntelliJ and Bloop seeing the same behavior.

@lefou
Copy link
Member Author

lefou commented Jul 23, 2021

So this isn't really an issue anymore?

@ckipp01
Copy link
Contributor

ckipp01 commented Jul 23, 2021

Correct. At least in the LSP world, if you look at the expanded range that LSP will report to the client, it will be correct. Metals actually has the ability to expand that point to the full symbol. I sort of misunderstood this in the beginning until the IntelliJ folks mentioned it as well. I believe this can be closed now.

@lefou
Copy link
Member Author

lefou commented Jul 23, 2021

Great, thanks for clarifying.

@lefou lefou closed this as completed Jul 23, 2021
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

No branches or pull requests

2 participants