tree 17419cd3931885886c1adaeb08ccbb7a3605a07a
parent ffc207509abf826f12724821620192fb29524064
author Heschi Kreinick <heschi@google.com> 1612925863 -0500
committer Heschi Kreinick <heschi@google.com> 1613510814 +0000

internal/lsp: refactor go command error handling

Our handling of go command errors was cobbled together, leading to
unexpected gaps and duplication. Refactor it to be more coherent.

Our goal is to turn every go command error into a diagnostic in the
relevant location. The errors don't contain error positions, so we have
to guess where they belong using the module names mentioned in the
error. If we can't find any reference to those modules, we are forced to
add diagnostics to all go.mod files.

I may have destroyed the intent of TestMultiModule_OneBrokenModule but
I'm not sure what to do about it.

Some cleanup along the way:
- Stop parsing modfile.Parse error text: it returns structured errors
and we can just use them.
- Return CriticalErrors from awaitLoadedAllErrors, and do error
extraction lower in the stack. This prevents a ridiculous situation
where initialize formed a CriticalError, then awaitLoadedAllErrors
returned just its MainError, and then GetCriticalError parsed out
a new CriticalError from the MainError we got from a CriticalError.
- In initialize, return modDiagnostics even if load succeeds: we are
missing packages and should not silently fail, I think?
- During testing I tripped over ApplyQuickFixes' willingness to not
actually do anything, so I made that an error.

Fixes golang/go#44132.
I may also have fixed golang/go#44204 but I haven't checked.

Change-Id: Ibf819d0f044d4f99795978a28b18915893e50c88
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291192
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>