commit | 1e7abacf3b50c924a87de1fb83a8fb62b44c374f | [log] [tgz] |
---|---|---|
author | Heschi Kreinick <heschi@google.com> | Tue Feb 09 21:57:43 2021 -0500 |
committer | Heschi Kreinick <heschi@google.com> | Tue Feb 16 21:26:54 2021 +0000 |
tree | 17419cd3931885886c1adaeb08ccbb7a3605a07a | |
parent | ffc207509abf826f12724821620192fb29524064 [diff] |
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>
This subrepository holds the source for various packages and tools that support the Go programming language.
Some of the tools, godoc
and vet
for example, are included in binary Go distributions.
Others, including the Go guru
and the test coverage tool, can be fetched with go get
.
Packages include a type-checker for Go and an implementation of the Static Single Assignment form (SSA) representation for Go programs.
The easiest way to install is to run go get -u golang.org/x/tools/...
. You can also manually git clone the repository to $GOPATH/src/golang.org/x/tools
.
This repository uses prettier to format JS and CSS files.
The version of prettier
used is 1.18.2.
It is encouraged that all JS and CSS code be run through this before submitting a change. However, it is not a strict requirement enforced by CI.
This repository uses Gerrit for code changes. To learn how to submit changes to this repository, see https://golang.org/doc/contribute.html.
The main issue tracker for the tools repository is located at https://github.com/golang/go/issues. Prefix your issue with “x/tools/(your subdir):” in the subject line, so it is easy to find.