Invalid diagnostic location after text edit

I'm not sure where I should report this issue, so here we go. It looks like the content of textDocument/publishDiagnostics that follows the textDocument/didChange is invalid.

What happens is as follows:

  1. I start with a diagnostic at the last line
  2. Backward delete a line

now what happens is sourcekit-lsp reports 2 notifications, one after another. First, behave like if buffer didn't update yet, and diagnostic is still at line 12, then right after that, there's another notification where this diagnostic is properly updated and located at line 11. It acts as it reports the intermediate state somehow. I confirmed this behavior with the current main (ef270137fe8ea03a032914f44a9ffd0e3fb11496) and binary from Xcode 13.2.1.

I was able to capture that in VSCode:

Screen Recording 2022-01-20 at 23_55_24

Looks buggy, thanks for reporting. CC @ahoppen

It's expected that there are two updates, and it's possible that in the first update the semantic diagnostics (e.g. cannot find 'app') are stale, because the first update is purely syntactic, but (a) we shouldn't get duplicate diagnostics like that, and (b) the semantic diagnostics should be range-shifted to the correct location even if we don't know yet if they're applicable (i.e. if your edit fixed the semantic error we wouldn't know that in the first update, but we should at least shift it to the correct location).

Thanks for reporting this @krzyzanowskim. As Ben mentioned, sending two PublishDiagnostics notifications is intended but it looks like the syntactic diagnostics report wrong line numbers. Maybe VSCode is getting confused because of this. I’m looking into it.

I also noticed from your screen recording that we only highlight the first character of the unknown identifier. I’m looking into that as well.

I just submitted Adjust diagnostic ranges on edits by ahoppen · Pull Request #447 · apple/sourcekit-lsp · GitHub, which should fix the issues.

1 Like