tree 2b7d02760a805a4d205ebfc906915781bf0779d6
parent 0c3ec398db4a7db90cb563b798a3f58f60b942e8
author Hana <hyangah@gmail.com> 1601993413 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> 1602005073 +0000

src/util.ts: handle diagnostics errors for all visible files

Error messages from lint, vet, or go compiler often contain only the
start position's line number, and sometimes the column info, even though
vscode's DiagnosticCollection expects complete Ranges (both start/end
positions).

In handleDiagnosticErrors, the vscode extension implements a heuristic
to fill in the missing fields to construct complete Range entries.
For the file that is open and visible when the lint/vet/go build runs,
it finds the corredponding row, sets the start position to be the beggining
of the non-whitespace text part if the start column info is not available
from the tool's error message, and sets the end position to be the end of
the non-whitespace text part. For errors that belong to files that aren't
open or do not have focus, it sets the start column 0 and the end column 1
unconditionally.

This had a side-effect as described in golang/vscode-go#743 - when multiple
files with problems are open, the error location info for the file behind
isn't completed in a way it would've been handled if it was on the top.
The location info is not completely incorrect in the sense that that's
what the underlying tool provided, but visually it is not great.

This CL makes two changes
 - Apply the handleDiagnosticError's heuristic to construct complete
   Range information to all text documents 'known' to vscode. Here 'known'
   text documents mean the document that is open and also vscode already
   loaded the file contents in memory. That means, it's possible that
   a file that is open but whose content is not loaded into memory may
   still exhibit the problem described in golang/vscode-go#743. But I don't
   find an efficient, clean way to handle the case.
 - Apply the column info from the tools if available, instead of using position
   0 unconditionally when the text document is not 'known' to vscode yet.

I expect in the future, gopls will handle vet/lint errors and provide
better range info than this, so this will become a more rare corner case.

Fixes golang/vscode-go#743

Change-Id: I5c953aa710a14a59d00ea7e94d4028ca05316362
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/259797
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>