Despite the name, ParseExported only hollowed out declarations -- it
didn't actually drop any from the AST. This leaves a fair amount of
unexported crud behind. Unfortunately, there are a *lot* of ways to
expose an unexported declaration from an exported one, and it can be
done across files. Because of that, discarding unexported declarations
requires a lot of work.
This CL implements a decent attempt at pruning as much as possible from
the AST in ParseExported mode.
First, we analyze the AST of all the files in the package for exported
uses of unexported identifiers, iterating to a fixed point. Then, we
type check those ASTs. If there are missing identifiers (probably due to
a bug in the dependency analysis) we use those errors to re-parse. After
that we give up and fall back to the older, less effective trimming. The
pkg type changes slightly to accomodate the new control flow.
We have to analyze all the files at once because an unexported type
might be exposed in another file. Unfortunately, that means we can't
parse a single file at a time any more -- the result of parsing a file
depends on the result of parsing its siblings. To avoid cache
corruption, we have to do the parsing directly in type checking,
uncached.
This, in turn, required changes to the PosTo* functions. Previously,
they operated just on files, but a file name is no longer sufficient to
get a ParseExported AST. Change them to work on Packages instead. I
squeezed in a bit of refactoring while I was touching them.
Change-Id: I61249144ffa43ad645ed38d79e873e3998b0f38d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312471
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>
If A is a type, then in
type B {
A
} it is a type, but in
type C {
A int
}
it is a variable (and similarly in function types). The old code got this wrong.
Fixes: golang/go#46068
Change-Id: Ib7320914de81d2b7377214f53f99f4fea25e00fb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/318749
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Tools like gopls will want to add additional features to support working
with generic code, but need to continue to compile at older Go versions
that don't support type parameters.
This CL contains an initial draft of a helper library that may be used
to interrogate generic type information from go/ast and go/types without
having to guard the calling code with a build constraint.
I will use this library to implement some generics features for gopls.
Once we're confident in the API, it could potentially be exported as
x/tools/go/typeparams.
Change-Id: I0ad3050b57cf8d8e8dda7d350d18f5e50f4105ff
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317451
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Sometimes users report issues related to edge cases in Gopls that aren't
reproducible. In some of these cases, we end up guarding against
conditions that shouldn't be possible, which is an unfortunately fragile
solution.
Add a new debug.Bug function to both annotate such branches as known
bugs, and help find them when they reoccur. For now this just records
them in the debug server, but in the future we could send the user a
message to the effect of "hey, a known bug has occurred" for debug
builds of gopls.
Also included are some minor cosmetic fixes.
Change-Id: I95df0caf2c81f430661cabd573ce8e338fa69934
Reviewed-on: https://go-review.googlesource.com/c/tools/+/318369
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: Rebecca Stambler <rstambler@golang.org>
When CL 241577 lands, 'go list -e' will include unparseable files
(like a file without a package declaration) in GoFiles in addition to
InvalidGoFiles.
This makes go/packages more tolerant of empty test files. With
CL 241577, if a file=src.go query is given when an empty _test.go is
present, packages.Load will return two matching packages: the library
under test, and the internal test package.
This CL broadens overlay_test.go so the new behavior doesn't break the
test.
For golang/go#39986
Change-Id: I14d019129465e928a3f60a2230edd2e2d1d74687
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317409
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Replace the link to the gopher pkg.png from an online location
to a local file.
This will prevent any privacy issue on godoc so that there is no ping anymore to golang.org
when opening private documentation generated by godoc.
Another benefit is that it allows the image to load when godoc is used offline.
Last the img is placed to the upper section.
For golang/go#32011.
Change-Id: I1459bf2613251e3e12404087ea9083b64a4f70c2
GitHub-Last-Rev: c32ef9541e8e927c40f99d161ffe6af4aa5b0258
GitHub-Pull-Request: golang/tools#315
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313097
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Rather than stating a neutral-sounding fact
(i.e., "Sprintf call has error-wrapping directive %w"),
make it more clear why this is wrong
(e.g., "Sprintf call has error-wrapping directive %w, which only operates with Errorf")
Change-Id: I3417423bcc09e6c9ede9993c33d8420ec57c2a08
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317431
Trust: Joe Tsai <joetsai@digital-static.net>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Support typeDefinition for functions/methods that have only one return value
of a named type. The total number of return values doesn't matter.
Examples:
* func foo() X
* func foo() (X, bool, int)
* func foo() (*float64, *X, error)
Fixesgolang/go#38589
Change-Id: I8840d667437300fd1250a13630e12a36601f0a60
GitHub-Last-Rev: 581d810af959f8b2c0bf62a22e5725f32947f5e4
GitHub-Pull-Request: golang/tools#311
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313093
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add a benchmark for the processing of workspace/didChange notifications,
attempting to isolate the synchronous change processing from
asynchronous diagnostics. To enable this, add a new type of expectation
that asserts on work that has been _started_, but not necessarily
completed. Of course, what we really want to know is whether the current
notification has been processed, but that's ~equivalent to knowing
whether the next one has been started. Really, it's off-by-one, but
amortized over e.g. the 100 iterations of a benchmark we get
approximately the right results.
Also change some functions to accept testing.TB, because in a first pass
at this I modified the regtest framework to operate on testing.B in
addition to testing.T... but that didn't work out as IWL is just too
slow to execute the benchmarks outside of the environment -- even though
we can ResetTimer, the benchmark execution is just too slow to be
usable. It seems like a fine change to accept testing.TB is some places,
though.
For golang/go#45686
Change-Id: I8894444b01177dc947bbed56ec7df80a15a2eae9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317292
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: Rebecca Stambler <rstambler@golang.org>
Leave the options flag so people can disable it for now if needed.
Updates golang/go#39507.
Change-Id: I78bbac157caa18c5d9a8e2ffe1a5c5eba4c6c30f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317389
Run-TryBot: Muir Manders <muir@mnd.rs>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Extend stdmethods to warn when a type implementing error has an Is, As, or Unwrap method with a different signature than the one expected by the errors package.
For golang/go#40356
Change-Id: Ia196bb83a685340d6dab216b87c8a4aa2846f785
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312829
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
In cases like:
append([]string{}, foo<>)
we now prefer objects of type string at <>. Previously we had no
preference. In particular, we now try to infer the slice type from the
first append() arg instead of only from the outer context of the
append() call.
Fixesgolang/go#43240.
Change-Id: I59dfa3b18892c5c87fc5ff53109f51f50ee03d26
Reviewed-on: https://go-review.googlesource.com/c/tools/+/316849
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Provide some support for template files, implementing most of
https://docs.google.com/document/d/1clKAywucZVBXvL_v4mMhLQXso59lmQPMk1gtSpkV-Xw
Template support is controlled by the option 'experimentalTemplateSupport'
which defaults to false.
Most of the code is in a new 'template' package. Implemented are
semantic tokens, diagnostics, definitions, hover, and references,
and there is a stub for completions.
This code treats all the template files of a package together, so as
to follow cross-references.
Change-Id: I793606d8a0c9e96a0c015162d68f56b5d8599294
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297871
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Peter Weinberger <pjw@google.com>
This change was produced using 'go mod tidy -go=1.17'
with a go command built at CL 315210.
This activates lazy loading, and updates the go.mod file to maintain
the lazy-loading invariants (namely, including an explicit requirement
for every package transitively imported by the main module).
Note that this does *not* prevent users with earlier go versions from
successfully building packages from this module.
For golang/go#36460.
Change-Id: I117d8ae9ea605a4c78ee6a0816739e74b09b2e48
Reviewed-on: https://go-review.googlesource.com/c/tools/+/316449
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
There are two possible quick fixes for a missing go.sum entry, and the
regression tests always run all available fixes. That never made sense,
but I never got around to fixing it because it didn't cause a problem.
Now that it turns out to be the cause of the problem described in CL
315152, fix it and roll that CL back.
Change-Id: I49430429a99a412f43bd11b30afe8903db99a694
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315910
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change was produced using 'go mod tidy -go=1.17'
with a go command built at CL 315210.
This activates lazy loading for the x/tools module, and updates the
go.mod file to maintain the lazy-loading invariants (namely, including
an explicit requirement for every package transitively imported by the
main module).
I will send a separate CL to upgrade the gopls module, since it has
some awkward interactions with the Go 1.12 presubmit test
(golang/go#45919).
Note that this does *not* prevent users with earlier go versions from
successfully building packages from this module.
For golang/go#36460.
Change-Id: I1d2a6b28820fa6cb3d02162c14873643e4c689cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315570
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
This enables the narrower "all" pattern described in
https://golang.org/doc/go1.16#all-pattern,
eliminating some otherwise-unnecessary checksums.
For golang/go#36460.
Change-Id: Ia894b1c1d85f8d1317aebb816921e95e7c1da506
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315569
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The window/showDocument RPC is now correctly classified as being
sent from the server to the client.
Change-Id: I659528af69662fb709242d326563d52070fd5702
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315990
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
I considered having gopls not initialize at all, but VS Code Go
intercepts those error messages and they get buried. We should probably
fix that in VS Code Go, but for now just show a warning.
Updates golang/go#45732
Change-Id: I214974e5a96231c96b1583af8ac245de03cea5d8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315852
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Clarify that we have best-effort support for the last 4 major Go
versions, and that support for Go releases 3 and 4 versions ago may not
block releases and may be dropped if necessary.
Also explain that Kokoro CI is not automatically re-run when the result
is removed in Gerrit.
For golang/go#45919
Change-Id: Ic1480c9276dad9502aaf885b98bb9445deeed0c5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/316349
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
ast.NewPackage mutates the input files, making it difficult to avoid
races with our caching model. I had avoided a race resulting from cache
handle cancellation, just to run into another race in multi-session
servers.
But there's no reason to use ast.NewPackage when we only have a single
file. We can just interrogate the file scope wherever needed.
Fixesgolang/go#45868
Change-Id: I521475b51ee3b1c3e408916affecafbc629b0191
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315629
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 LSP, CompletionItems can say if they are for deprecated names. This
CL implements that for items where the doc comments contain a line
starting // Deprecated.
Semantic tokens now similarly mark deprecated tokens, but in vscode
the default theme doesn't change the display, and the customization
options seem limited to:
"editor.semanticTokenColorCustomizations": {
"rules": {
// only foreground, bold, underline, italic
"*.deprecated": {"italic": true}
}
},
Change-Id: I93ccc227bf4e1e30a4f23b40da4d2cbafe1cd925
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313509
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
There's no easy way to do this via the LSP, as go/packages reads from
the environment, so simply call os.Setenv.
Fixesgolang/go#45866
Change-Id: Iae4e929d47ffef5ffe023ed1886d773a74fd836f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315649
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For some reason the "bad" case of this test fails when the main module
is lazy. Since the go.mod file lacks a 'go' version directive, as of
CL 315210 it is upgraded to a lazy module the first time it is edited
by an invocation of cmd/go.
I don't know why this case doesn't exhibit the expected failure mode
when lazy loading is enabled — I guess it's because we attribute the
checksum error to the individual package that needs it instead of the
module as a whole? — but I can't follow this test well enough to
figure out whether there is actually a real problem for lazy modules
here. If there is, we can handle that by adding a new, separate test.
For golang/go#36460
Change-Id: I0949e1f9f5cb1b6c884706e50a9694232308387b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315152
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Now that this issue has been resolved, we can unskip the tests for it.
Change-Id: I610122a424bedd2cbd066ea9985239fc319e58ae
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313532
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>
Calling PackagesForFile on builtin.go loads is at a
command-line-arguments package, which has many type checking errors.
Add a new snapshot method IsBuiltin, which is used to avoid calling
PackagesForFile on builtin.go when diagnosing changed files or checking
for orphaned files. There may be other places where this should be used,
but this functionality can't reasonably be pushed down, as
PackagesForFile should always return something.
This exacerbated an existing race to building the builtin, because
ast.NewPackage unfortunately mutates the ast.File. Fix this by just
building the builtin package directly when building the handle. It
should be very fast.
Fixesgolang/go#44866
Change-Id: Ie6c07478493fa011e92e6966289c2fa822d87b35
Reviewed-on: https://go-review.googlesource.com/c/tools/+/314290
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>
For golang/go#37098
Change-Id: I6edf1b4efca38fe9837ed944bc45c05c37099b4a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313591
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Due to the limitations of comments in ast, it is difficult to move
comments. The extract function feature currently does not handle
comments at all. This change instead prints the comments that would
have been lost above the call to the function, so that the user can
easily recover them. Otherwise, it was possible for users to lose
comments and not notice.
Updates golang/go#37170
Change-Id: I1e2d865f5deddefbb0417732490decbdfcde5f3d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313211
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
It wasn't obvious that there are two different kind of diagnostics
reported by fieldalignment, one for struct size and another for pointer
bytes.
The documentation now mentions both types, and shows an example that
clarify what "pointer bytes" are.
Fixesgolang/go#45541
Change-Id: Ia62fb05980ddddf52e579ac51459aaaed168cfa7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/314469
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
If there is a return statement that is guaranteed to execute in
the selection to extract to function, then the result of calling
the extracted function can be directly returned.
Updates golang/go#37170
Change-Id: I6454e4107d670e4a1bc9048b2e1073fc80fc78ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312469
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Before this change directory names were used "as is" for package completion.
It could lead to invalid suggestions (for example, 'package 1abc' or package 'ab-cd').
This change adds a check whether a directory name can be used in a package path.
If the directory name is invalid, only 'package main' will be suggested.
Otherwise, the directory name will be normalized and will be used as a package name.
Note: normalized directory names contain only lower case letters and digits.
Fixesgolang/go#44680
Change-Id: I4b710f90d1723c512e29dc3c248a1e681f1cd37f
GitHub-Last-Rev: 8ae69f1c6fdf80831e5773bdb3507a8d51a4a0cf
GitHub-Pull-Request: golang/tools#310
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313092
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Updating server info was racing with rendering debug templates, because
the state mutex only guards the servers slice, not the values contained
in that slice.
Switch to splicing in updated server data, rather than updating
in-place, to avoid the race.
Change-Id: Ia69895b49cf3f961c58db8e6512ce8b1f5911fd3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/314169
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: Rebecca Stambler <rstambler@golang.org>
Rename the 'inspect' command to 'remote', since it makes more sense for
the command to be scoped to interactions with the gopls remote. Add a
new subcommand 'debug' to start the debug server. Leave an aliased
'inspect' command for now. I'm 99% sure nobody is using it, so we can
remove the alias in a month.
Move some things around in the lsprpc package to improve factoring a
bit.
Fixesgolang/go#45518
Change-Id: Ic6d64204611552e593dcbc1b5a347ccd27a4f40c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309810
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This test checks that if a single value in the Initialize message
changes, the resulting unmarshalled struct changes in no more than
one place. The implication is that ignoring UnmarshalTypeErrors
in LSP processing is safer than causing a fatal error, which is the
current state.
Change-Id: I64bbf6f785c32fa7483966a117ac3b6f11d573be
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310109
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 313251 fixed the describe test, but inadvertently broke the referrers
test due to changing line numbers in describe/main.go. This CL amends
those line numbers.
Fixesgolang/go#45778
Change-Id: I1dbdd9157091e061bfa35ec0b5c4690aa09ae092
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313669
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: Bryan C. Mills <bcmills@google.com>
Go 1.17 adds the unsafe.Add and unsafe.Slice functions, which causes the
guru describe assertions about unsafe to either fail at 1.17 or fail at
earlier Go versions.
This is causing the longtest builds to break.
Remove them for now. If we remember, we can add them back once we no
longer support 1.16.
Fixesgolang/go#45778
Change-Id: Ie72355fbab8e614c0150097c84c796e78d968839
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313251
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The existing implementation uses a lot of URI.Filename() calls,
which are pretty expensive. Moreover, these calls are not necessary,
as long as all the actions could be done with the raw URI string.
This patch removes such calls and uses simple string casts.
Updates golang/go#45686
Change-Id: Ibe11735969eaf0cfe33024f08418e14bf71e7fc4
GitHub-Last-Rev: 67a3ccdf30a6a99bc1b5a8e9cd2a7c0865d894d0
GitHub-Pull-Request: golang/tools#306
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312809
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The utility of the debug server is limited by the requirement to start
gopls with the `-debug` flag and then look in the logs to see which port
the debug server is bound to.
This CL adds a new custom command `gopls.startDebugging` to start the
debug server on demand if it isn't already running, and return its debug
address. It also does some gymnastics to make this turn on debugging for
any intermediate gopls forwarders, when using daemon mode.
For golang/go#45518
Change-Id: I48a90088f96aca54f34f93bedbfe864515320f61
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309409
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: Rebecca Stambler <rstambler@golang.org>
In cases like:
foo.<>
bar = 123
We weren't detecting that the selector preceding <> was a statement.
The above is parsed as "foo.<>bar = 123", so it looks like <> is
contained in an AssignStmt. This matters because we give different
postfix completions depending on whether it is valid to replace the
surrounding selector with a statement or not.
Updates golang/go#45718.
Change-Id: I8f74505b2c8c7060f1e94433904ff0a987d0cc57
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313269
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
For large codebases, the cost of copying these maps can be fairly high,
especially when it needs to repeatedly grow the map's underlying storage.
Preallocate these to the size of the original snapshot maps to prevent
the need to grow the storage during the clone.
Updates golang/go#45686
Change-Id: I4cfcd5b7cba8110e4f7e706fd9ea968aaeb6ff0c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312689
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: Rebecca Stambler <rstambler@golang.org>
We still hear from users for whom gopls uses too much memory. My efforts
to reduce memory usage while maintaining functionality are proving
fruitless, so perhaps it's time to accept some functionality loss.
DegradeClosed MemoryMode typechecks all packages in ParseExported mode
unless they have a file open. This should dramatically reduce memory
usage in monorepo-style scenarious, where a ton of packages are in the
workspace and the user might plausibly want to edit any of them.
(Otherwise they should consider using directory filters.)
The cost is that features that work across multiple packages...won't.
Find references, for example, will only find uses in open packages or in
the exported declarations of closed packages.
The current implementation is a bit leaky; we keep the ParseFull
packages in memory even once all their files are closed. This is related
to a general failure on our part to drop unused packages from the
snapshot, so I'm not going to try to fix it here.
Updates golang/go#45457, golang/go#45363.
Change-Id: I38b2aeeff81a1118024aed16a3b75e18f17893e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310170
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Heschi Kreinick
pjw
Rebecca Stambler
Rob Findley
Pen Tree
Jay Conrod
Tom Freudenberg
Joe Tsai
Shoshin Nikita
Muir Manders
Tim King
Bryan C. Mills
Ian Lance Taylor
Suzy Mueller
Pontus Leitzler
Anton Kuklin
Hossein Zolfi
William Langford