Rather than using the directory of the package, store the package ID and
calculate the directory in GCOptimizationDetails. I think this is
slightly more readable/cleaner.
Change-Id: I13cac8a7552b73b2bd5d25ff582b5d4936a74827
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297877
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: Robert Findley <rfindley@google.com>
The URL regexp is apparently enormous and we spend 13 CPU-seconds
compiling it in the gopls version of the LSP tests.
Change-Id: Id291ce0f104aa02b5e38aad43fff8647ce1b5b98
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297876
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: Robert Findley <rfindley@google.com>
CL 295414 suppressed all type checking errors in the presence of parser
errors, but this was a bit overzealous. go/types attempts to suppress
follow-on errors from bad syntax, so as long as we haven't had to modify
the AST and the current file parses, type checking errors can still
provide a decent signal to the user
Fixesgolang/go#44736
Change-Id: Icd89404fbae663b8f934a38908eaaa87c561b64a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297872
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In practice, the only code shared among the various switch cases was the
call to spanToRange, which definitely doesn't justify the giant
function. Split it out into per-type functions.
I removed the unused case for types.Error, and a bit of error checking I
believe to be redundant. I don't intend any functional changes.
At this point it might be worth considering moving the functions into
other files, but I don't think it matters that much.
Change-Id: I05b4d86dd37a9ff1887a116183c915c225faf3a7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297129
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>
Hopefully improve some of the details around parsing that have always
confused me.
- parser.ParseFile will never return an error other than
scanner.ErrorList. Encode that in ParsedGoFile.
- parser.ParseFile will never return a nil file. Eliminate the code
path that handled that.
- Explain why we might fail to find a token.File.
- Trying to fix errors appears quite expensive even if there aren't any
to fix. Don't waste the time.
Change-Id: I87e082ed52c98a438bc7fd3b29e1a486f32fb347
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297069
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>
When a //go:embed or //go:build (//+build) line changes, we need to
invalidate metadata. Do so. It might be preferable to only invalidate on
save, but we don't currently have an approach for doing that. So for now
we'll load on each keystroke in a magic comment.
Fixesgolang/go#38732, golang/go#44342.
Change-Id: Id05fb84f44215ea6242a7cf8b2bca4e85f74680e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296549
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>
go/packages.Error has filenames relative to the go command's working
directory. We need to interpret them as such.
This would perhaps be better done in go/packages but with no release
process in place I'm leery of making changes to it.
Updates golang/go#44342.
Change-Id: I95bcdff0368efe09ec7059394e59a39bf195310b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295412
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>
In typeCheckDiagnostics, we have logic to suppress go list and type
checking errors based on the presence of other errors. Nobody seems to
know why the logic is exactly what it is, and suppressing list errors
means that bad //go:embed patterns don't show up.
Intuitively, it makes sense to me that we don't want to type check if
listing or parsing fails: list errors mean that whole files may be
missing, and parsing errors may wipe out arbitrary chunks of files.
There's little point reporting errors from type checking that. However,
list errors and parse errors should be mostly orthogonal: go list
parses very little of the file and in practice only reports errors
parsing the package statement. So, at least for now, we report both
parse and list errors, and stop there if there are any.
Finally, move the suppression logic to the actual typeCheck function
that generates the diagnostics. typeCheckDiagnostics is the primary
consumer, but I think it's better to do the suppression at the source.
Because we are now showing list errors, and they are prone to getting
stuck due to bad overlay support, a couple of tests now require 1.16.
Change-Id: I7801e44c4d3da30bda61e0c1710a2f52de6215f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295414
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: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Due to misuse of the expandErrors function, when we encountered a
continuing error, we would group all the related errors into a single
one, then return both it and all its secondaries individually. That
makes for a strange user experience where you get one complete error and
N-1 incomplete ones.
Instead, create a copy of the complete error for each secondary error,
moving the copy to the location of the secondary error and adding a bit
to the text to (hopefully) clarify what's going on.
Change-Id: I87cf0e3b2cea98317f650d16a78476edf108a934
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295413
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>
Rewrite eg to use go/packages, so that it works with Go modules.
There are two known regressions:
* lost build tag support
* you can't use a template to add a new dependency
These can be re-added at a future point as needed.
Change-Id: I2b59bb5e101c738a4d4c40e84a12c5b3a19bcd18
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258304
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The /share registration is not needed by programs like
talks and blog, only by golang.org, so installing it by default
is unnecessary and perhaps more exposure than people running
those servers intend.
Add Proxy to allow recreating the /share registration (unlikely)
or installing the proxy on an alternate mux (more likely).
Change-Id: Ibb33add804d353920d405bf022428e48b3815da3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293449
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The go/types fix for golang/go#44515 changed the type string for unsafe.Pointer
from a fixed "unsafe.Pointer" to a customizable package path followed
by "Pointer" (the customization was in place for any other object already).
The package path customization is done through a user-provider types.Qualifier
function. If none is provided, the ordinary package path is used ("unsafe").
Guru provides a package-relative qualifier which leaves away the package
path if an object is local to a package. As a result, unsafe.Pointer is
printed as "Pointer" which breaks an existing test.
Provide no qualifier function when printing a type from package unsafe
instead (there's only unsafe.Pointer). Since no qualifier was used in
the past, this Guru-specific change will also work when run using earlier
Go versions.
Fixesgolang/go#44596.
Updates golang/go#44515.
Change-Id: I3c467e4ed09aa13deb50368fe98e42c723a6376b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296289
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
According to https://golang.org/doc/go1.14#runtime
A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS
systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases.
This causes syscall.Open and syscall.ReadDirent sometimes fail with EINTR errors.
We need to retry in this case.
Fixesgolang/go#44478
Change-Id: I0b0291471e47e8682fac791e1ed024b5a42a56f8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294730
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Vet complained about multiple definitions of the 'workspace' tag.
The underlying error was a failure to do type merging in alias types,
coupled with relying on luck when generating types and deciding which
type definitions to store. (Luck almost worked, but more careful type
merging made it too risky.)
The only noticeable change (outside tsprotocol.go) is that the
generated type names used in general.go now have serial numbers in them.
tsserver.go and tsclient.go just have new dates in their headers, but
are otherwise unchanged.
tsprotocol.go has more generated types (Workspace.*Gn). (There are
probably more types than are needed, but fixing that is for the future.)
All the tests pass and gopls seems to work ok. The revised code.ts will
be submitted in a future CL.
Change-Id: I7082755c327e7b6ebec57d4449eec1e0cc50fcd5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294909
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Without this parser mode, go/parser will bail out and return no comments
from a parsed file if there are more than 10 errors. This can lead to
tests silently not running, as noted in the TODO right above the parse.
This can still happen: poor parser recovery could result in comments not
being parsed. However, the parser is generally pretty good about
preserving comments, and anyway passing parser.AllErrors means that
adding a single new error to a testdata file will not suddenly cause all
errors in that file to be ignored.
Change-Id: Ib3c22944999651018d38fa6ce5c5a11ac6853aa0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293932
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
### gopls
- Add `https` scheme to `CodeDescription.href`
According to the [LSP specification](https://microsoft.github.io/language-server-protocol/specification#diagnostic), `CodeDescription.href` must be [URI type](https://microsoft.github.io/language-server-protocol/specification#uri). As described in the [RFC](https://tools.ietf.org/html/rfc3986#section-3), the scheme is required for URI:
> The scheme and path components are required, though the path may be empty (no characters).
Current `gopls` does not add the scheme to `CodeDescription.href`, and this results in some LSP clients ([at least this client](https://github.com/autozimu/LanguageClient-neovim)) which are strictly validating the URI format to be failed to populate diagnostics.
Change-Id: I73f01c2e97ed1adb62fbed451a7c9b0c9794b66a
GitHub-Last-Rev: 6985bfe60e182ee788082d8fcb9515275d9612fa
GitHub-Pull-Request: golang/tools#277
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294569
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Not strictly necessary but will avoid gofmt changes later
as people edit these files.
Change-Id: I20749ed82e18938a305d9425d0739f0ea7bd24c0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294414
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
The Go 1.17 gofmt will insert the extra //go:build lines.
The older gofmts will not remove them.
Get ahead of the game by adding them now.
(Keeps x/tools tests passing on go repo trybots.)
Change-Id: Ifdb4af93f6cc38a9aa616516e923384b7312e991
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294413
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This checker checks for instances of writes to struct fields and arrays
that are never read.
Change-Id: Ibeb4fc45d7b87a2ea571ba23a29ec44529623f0d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287034
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Tim King <taking@google.com>
After playing with these a little, they definitely get the job done.
But I'm already seeing a few ways the API could be nicer (e.g.,
provide a bundle-backed go/importer.Importer implementation that reads
packages out on demand, so unneeded packages don't need to be read).
So mark these APIs as experimental so users know not to get too
attached to them just yet.
Change-Id: Idb98f45095a0c6f9825ff07172f62c42d8453016
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294310
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The comparable interface is introduced on the dev.typeparams branch.
Filter it out from gopls completion results so that it doesn't break
tests on the dev.typeparams branch.
Change-Id: Iba22c0980c09e99b454ce9e22813cc3a1f94a90c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293931
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Report misplaced and malformed //go:build lines,
like we've always done for // +build lines.
Report when the // +build lines do not say the same thing as the //go:build line.
(Running gofmt will always bring them back in sync.)
For Go 1.17 vet.
Change-Id: Ifd22c6e8edcfeedc37851ba514712c5c057ad4b8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293834
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TestFillStruct had an unnecessary dependency on the go/types.Info API.
Break the dependency.
Change-Id: I7cacd045487e3a7d2ba92a6f76f6b37e0ea33bfb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293929
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I7bb1caf63772a460206dd6ca0a35b11a61ca162f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293531
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Previously, we were running `go get` only on modules, which led to us
not downloading dependencies of packages. This resulted in further
go.mod diagnostics that users could not resolve with quick fixes. Now,
download packages directly so that dependencies are downloaded.
Fixesgolang/go#44307
Change-Id: Id764ea5a2f7028e238eadaaba0ca3cfc765b85b4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293729
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
If pkgdir uses a symlink (e.g., how the macOS builders are currently
setup for their GOROOT, due to how /var and /tmp work there), then
changing into that directory to invoke cgo means that cgo will only be
able to see the actual directory it was run from. This can lead to
inconsistencies with code that expects to see the original
symlink-based path.
This CL changes go/internal/cgo to instead use cgo's -srcdir flag so
that cgo can emit //line directives with the symlink paths instead.
Fixesgolang/go#44339.
Change-Id: I3cbee6753454922711c8c70d7c64a02565b8bb4c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293250
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a lead-up to a change to create a better help messages in the go command.
Change-Id: I695fd2bf5420a62774334c77788e67565d3965c1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291909
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Change-Id: Ifb3f1b03a8e0b58465e088cdda3e0357ce648124
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293249
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It appears that /var/folders is a symlink to /private/var/folders on
macOS, and further that go/loader uses the original name whereas
cmd/compile uses the dereferenced name. (Judging based on error
messages.)
Change-Id: I3515b223031e3e7a1508acfdbb6dca3009ead398
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292910
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Export data is self-contained, which is convenient for ensuring the
compiler only needs to open export data files directly referenced in
source file import declarations. But it does have a consequence that
export data files can redundantly encode information.
This CL adds a new "bundled" export data format that allows encoding
multiple complete packages together so they can share transitive
declarations. This is intended to be useful for storing a compilation
unit's source files along with any export data they depend upon for
efficient re-type-checking and analysis later.
Change-Id: I720a12cb051767f9d7ce95d645b448043a1e2167
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292352
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The current versions of the indexed export format encode constant
values based on their type. However, IExportData was encoding
constants values based on their own kind instead. While cmd/compile
internally keeps these matched, go/types does not guarantee the
same (see also golang/go#43891).
This CL fixes this issue, and also extends testing to check reading in
the compiler's export data and that imported packages can be exported
again.
Change-Id: I08f1845f371edd87773df0ef85bcd4e28f5db2f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292351
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL reorganizes the iexport tests somewhat in preparation for the
subsequent CLs. No significant behavioral changes.
Change-Id: Ib7fc987b4733fcd6b47e658bbf0c613c431122b7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292350
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
In gcexportdata.Write, we ultimately write output to an io.Writer, so
we might as well do the same in IExportData. Also, omit the "i" prefix
here (to match IImportData's expectations), and add it back in
gcexportdata.Write instead.
Change-Id: I42dc577477587cd4ad6e943822dcea90e01bc236
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292349
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
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.
Fixesgolang/go#44132.
I may also have fixedgolang/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>
We haven't been able to reproduce this scenario, but it may be possible
when the user is in a broken state. Avoid panicking by gating every
use of obj.Pkg() with nil checks.
Fixesgolang/go#44300
Change-Id: Ia0c56a7fd5d6b89795dded1efdf05838f3de8209
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292671
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
It makes more sense to handle the import shortcut behavior at a higher
level anyway, so pull it out of findIdentifier and add a test for the
configuration.
Fixesgolang/go#44189
Change-Id: I96f08c7def154f6761efa727d693fdfb2fb722ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/290789
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Before go1.16 was cut, I made one breaking change to the error codes,
inserting a new code value in the middle of the enumeration. Sync to
pick up this change. In the future, such breaking changes won't be made.
Change-Id: I1ee0d78a11971013b38a370207e1d472065a02d5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292669
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change brings in a static analyzer that was created by
Orijtech, Inc. to detect the use of unbuffered channels with
signal.Notify, which is a bug that's documented but not enforced.
We've found it even in official examples and in the main Go
repository as per https://go-review.googlesource.com/c/go/+/274332.
We've found that this bug is very common in lots of Go code,
hence the reason why we are directly donating it, so that all
Go developers running go test, using gopls can use it.
Updates golang/go#9399
Change-Id: Ief6d7238dc80bc9fd5f11a585e41387704457276
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274352
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
errgroup.Group.Go(f) executes f asynchronously in a Go routine. This Go call is used quite often in Go projects.
Change-Id: I397af118300a25a5c38dbce83fcead974b58cef2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287173
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Trust: Tim King <taking@google.com>
findFile has a case that returns early if the file does not exist.
Handle this error in getFile to avoid inconsistently returning errors
when getting file handles for files that don't exist.
Unskip the test, since it is no longer flaky.
Fixesgolang/go#44227
Change-Id: I07a4f860cfc9f852728c31706bd924e419bd54e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291391
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Iterating through the map means that the ordering changes, which may
result in us creating different workspace module files for the same
workspace. We should be careful to always create the same file.
Change-Id: I4ccd3f9ebbbe81bb062285fe9c3ad675bdf2e53a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291493
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>