Optimize building the symbol index for a file, in two ways:
- use the cached full parse tree, if it already exists
- if it doesn't exist, optimize parsing by skipping both comments and
object resolution, which aren't necessary for symbols
This results in around 3x faster initial indexing of symbols. In my
manual testing, indexing of Kubernetes went from 16s->5s, and indexing
of x/tools went from 2.4s->700ms.
Also fix a typo in gopls/internal/regtest/bench/bench_test.go.
Fixes#52602
Change-Id: I0893e95410be96e94e5e9dee7a3aab30b59c19c5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403679
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This avoids an import cycle that prevented these wrappers from being
used in the lsppos package.
Change-Id: I9eedd256db983dfcf962edba39e3d4f3a1aabdeb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403680
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
For use-cases that work only with token.Pos and protocol.Position, the
span package is unnecessarily indirect, and inefficient. It also loses
information about newline termination, and handles positions within CRLF
line endings incorrectly.
The lsppos package was written to bypass this complexity, but had
limited use and lacked tests.
Add tests, and an wrapper API that operates on token.Pos. Also fix
source.TestTokenOffset to not panic, and add a temporary exemption of
the new token.Offset usage.
This change also fixes position calculation in the case of empty file
content. The mapper now finds position (0, 0) at offset 0 of an empty
file.
Change-Id: I639bd3fac78a127b1c8eddad60b890449901c68c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403678
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead of invoking the command through the LSP custom command,
call the vulncheck command hook directly. That reduces the extra
overhead of bringing up the full gopls server & package loading.
The vulncheck hook loads packages again any way, so the benefit
of running the check inside gopls's custom command framework
is not huge any more.
Still `gopls vulncheck` is useful - editors don't need to install
another binary for vulncheck feature, and it will output the
result in the format easier to handle than what `govulncheck`
currently offers.
Updates golang/go#50577
Change-Id: Ia21e6d7e0c37c4a1b02dc8bbca860143524c3d1b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/404574
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
While working on golang/go#52715, I discovered an infinite recursion in
gopls' completion logic: eachField assumes a finiteness of type pointers.
It is almost certainly a go/types bug that type-checked types expand
infinitely, but nevertheless we should use the more accurate
typeutil.Map for short-circuiting our search.
Change-Id: Ib1c7125e624f42882869acd4e0476e317d4da056
Reviewed-on: https://go-review.googlesource.com/c/tools/+/404335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Provide a default value for unsafe.Pointer in fillstruct.
Fixesgolang/go#52640
Change-Id: I10a1878fbf53b082f83f44e0ba2788ead14439d6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403535
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: David Chase <drchase@google.com>
'gopls help cmd...' is redirected to 'gopls cmd... -h'.
The tool.Run operation for each subcommand already has
logic to show the usage message when it parses a -h flag.
Examples:
$ gopls help
$ gopls help remote
$ gopls help remote sessions
Fixesgolang/go#52598
Change-Id: I5135c6e7b130d839f880d0613534ac08de199bcf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403677
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When a file is new or its package name has changed, we should invalidate
all packages for files in the current directory, not just packages
previously containing the file.
Fixesgolang/go#52500
Change-Id: I9fc9857a7abcd4e730068871c899d274e1736967
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401795
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Give placeholders for type params in func literal completions. For
example:
func foo[T any](func(T) T) {}
foo(<>)
Will now give "func(<T>) <T> {}" where <> denotes a placeholder.
Change-Id: Iadde73ed6b88e1410c28dfa33a20ab6a51235c93
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400616
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In cases like:
type foo[T any] struct{}
func bar[T any](foo[T]) {}
bar[int](<A>)
bar(<B>)
At <A> we will now offer "foo[int]{}". At <B> we will now offer a
snippet "foo[<T>]{}" which lets the user fill in the type arg.
Note that we have no knowledge of type inference, so you can be left
with superfluous type args after completion.
Change-Id: Ia7d63284f3317d9367864fdae3e3f9ae68fdff1a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400615
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In cases like:
func foo[T int | string](T) {}
foo[int](<>)
Previously at <> we would favor int and string candidates. This is
because go/types doesn't instantiate foo in this case (for some
reason). Work around the issue by using types.CheckExpr to re-check
the *ast.CallExpr.Fun. CheckExpr seems to do a better than a full type
check in the face of errors.
Updates golang/go#52291
Updates golang/go#52503
Change-Id: Ide436428f3232db2e06ea3cc22ea250edbf28685
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400614
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
changes
In principle, we should only parse through the cache when in workspace
mode, else we risk pinning AST in memory that we'll never need.
Alternatively: when unsure we should default to NOT parsing through the
cache.
For now, just update the logic to check for metadata changes to not
memoize its result.
Change-Id: I200af9ffb3353ba8065e46100a588dce6239dc66
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401794
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Update FindHoverContext to retrieve & render package documentation for a hovered package. Add a regtest for this hovering feature.
Updates golang/go#51848
Change-Id: If57396d59be9c4cf7e09b64e39832de6f996c7ca
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400820
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Dylan Le <dungtuanle@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In cases like:
func foo[A int|string](a A) {}
foo[_](<>)
We now prefer ints and strings at <> by matching against the type
constraint. Note that even if "_" is replaced with "int", we still
prefer strings since the type checker doesn't seem to want to
instantiate foo unless the params check out.
Change-Id: I0e7acfef0775752a96fcfe23e7e2e3d939820eee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394017
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Auto-Submit: Peter Weinberger <pjw@google.com>
As of golang/go#50827, gopls no longer needs to build at Go 1.12. This
was the only reason to continue using xerrors in the jsonrpc2 libraries.
Remove this usage as a step toward eliminating the xerrors dependency
from x/tools.
For golang/go#52442
Change-Id: I1a0a1bbf57e6606c66b99b27439adf6f65c26a60
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401155
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
As of golang/go#50827, gopls no longer supports building at 1.12, and so
usage of golang.org/x/xerrors can be replaced with the native support for
error wrapping introduced in Go 1.13.
Remove this usage as a step toward eliminating the xerrors dependency
from x/tools.
For golang/go#52442
Change-Id: Ibf459cc72402a30a6c2735dc620f76ed8a5e2525
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401097
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This change uses the new feature on the go command to explicitly ask
for needed fields on the JSON output to ask for needed fields. Not
requesting most of those fields doesn't make as much of a difference,
but being able to skip Deps and Stale should add decent gains in most
cases.
Change-Id: I30e9d53fbdaf2ab485d73d5d9b9ccd60a78ed10c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/393017
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The JSON-RPC 2.0 protocol requires that responses objects
have either a "result" or an "error", but not both.
In Go, this corresponds to a non-nil result interface value or a
non-nil error.
However, the generated wrappers for the LSP protocol were passing
non-nil values for both in case of error, due to passing typed-nil
pointers as (non-nil) interfaces (see
https://go.dev/doc/faq#nil_error).
This change fixes the generator to explicitly pass only one or the
other, and re-runs the generator at the existing commit.
For golang/go#49387
For golang/go#46520
Change-Id: I582b52820bdac15d9f947e8d6c1e9daa70c53e40
Reviewed-on: https://go-review.googlesource.com/c/tools/+/388600
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The documentation for jsonrpc2.Replier states that
“[i]f err is set then result will be ignored.”
jsonrpc2_v2 documents no such affordance, and the JSON-RPC 2.0
protocol explicitly requires that the result “MUST NOT exist if there
was an error invoking the method.”
Although CL 388600 already avoids returning values in case of error
(which may also help with escape analysis and/or allocation
efficiency), it seems simplest and least confusing to make the
semantic difference between the jsonrpc2.Handler and
jsonrpc2_v2.Handler explicit in the code.
For golang/go#46520.
Change-Id: If13eb842505d42cbc51c01f5f5e699a549a3a28b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400054
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Gofmt to update doc comments to the new formatting.
(There are so many files in x/tools I am breaking up the
gofmt'ing into multiple CLs. This is the leftovers.)
For golang/go#51082.
Change-Id: Id9d440cde9de7093d2ffe06cbaa7098993823d6b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399363
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Gofmt to update doc comments to the new formatting.
(There are so many files in x/tools I am breaking up the
gofmt'ing into multiple CLs.)
For golang/go#51082.
Change-Id: Ife11502fe1e59a04d53dba9edccd3043e57f9ae8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399358
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Running go mod vendor can result in vendor/modules.txt being transiently
deleted while it is being updated. On Windows this introduces potential
problems with file locking, if modules.txt is being read by another go
process, such as an ongoing package load.
Change the command to use RunGoCommandPiped, which executes serially
within the gopls process.
For golang/go#49646
Change-Id: If2d1fe5431122ba05014051a0e9c303cf7ee9cb2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399714
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When polling for on-disk file changes, we must detect changes even if
there is no change in the file since the last polling.
The reason for this is that there could have been intermediate changes
to the file that affected our calculations, and those calculations must
be invalidated.
For golang/go#51930
Change-Id: I92f5c34f982970d8386fddfaa22b82ba471e22e7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399625
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Upgrade staticcheck to v0.3.0 to pick up support for generics. Since
this version only supports Go 1.17+, increase the version at which we
install staticcheck to 1.17 (from 1.15). This change is likely to cause
confusion for users on Go 1.16, so show a warning when setting
the "staticcheck" option to an unsupported value. Slightly refactor our
setting of options along the way.
Fixesgolang/go#52159
Change-Id: Id9b4cee340e31988c64ca712d98573343aaf5848
Reviewed-on: https://go-review.googlesource.com/c/tools/+/396974
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Fixes: golang.org/#52024
Change-Id: Ib79a839f9bdeaef1250925add69dea3ae32e1cae
Reviewed-on: https://go-review.googlesource.com/c/tools/+/397479
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Peter Weinberger <pjw@google.com>
This is a minimal fix for the reported panic. The existing code
used FileSet.Position() where it should have used FileSet.PositionFor(, false).
gopls does this in lots of places; each use of Position() needs to
be thought about.
x/tools/go/ast/astutil/import.go:273,274 is another example.
Fixes: golang/go#51916
Change-Id: I42de6affca2c97c09efb7974a9e44322556b3ffd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/398395
Run-TryBot: Peter Weinberger <pjw@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Peter Weinberger <pjw@google.com>
The directory for the vulncheck command is passed
as an argument. Use the specified directory
in the configuration.
Change-Id: I1824b308701fd30548efa8bec7452de1fdf76bb9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/398394
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: I13cf73d7e043dda1a06c28bb09e413a76a68df1f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/391934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
When using gopls remote, existing go env vars are injected in the
initialize message. Setting GOWORK explicitly will impact cmd/go
invocations, for example "go list" during package load. The reason it
impacts is that gopls manually sets PWD to fix paths returned by cmd/go
if the working directory is inside a symlinked directory.
By only propagate GOWORK when it is explicitly set we will ensure that
the behavior is the same when running with or without remote.
See golang/go#51823.
Fixesgolang/go#51825
Change-Id: I6280aa7d8208e5aee269f19356668c7713e9f0a4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394054
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Current implementation returns incorrect result when some of the items are skipped, because positions could be relative to a skipped item. Instead, each position must be relative to the previous item added to the result.
Change-Id: I3c1a68d37bf0c9cfc1bccfe6f76c25b536224293
GitHub-Last-Rev: 6eedc7cbcc27f47ed5742b340f4438291ab70863
GitHub-Pull-Request: golang/tools#376
Reviewed-on: https://go-review.googlesource.com/c/tools/+/396715
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
Trust: Suzy Mueller <suzmue@golang.org>
internal/gopathwalk.walk remove an unnecessary call to os.Lstat when
checking if a symlink should be traversed. And remove a call to
filepath.EvalSymlinks that should be unnecessary as we are using
os.Stat to compare files.
Change-Id: Ie5ad1cb99cbd6d62f08f2b482a3e84b6fe41114d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/392095
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
beginFileRequest returns a nil error when file request url is
not a valid file url format. This is reported with a separate 'ok'
boolean return value.
This bug caused custom gopls commands to return success with
an empty result, instead of reporting the problem as an error.
Change-Id: I8eed39368087fa9928bcc68853225ea432f500d2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395814
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Jamal Carvalho <jamal@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We do a lot of gymnastics to format var types, working around the lack
of alias tracking in go/types. As part of this, we clone and qualify
expressions. In this case, we were not qualifying identifiers that were
contained within fields or field lists.
Fix this by updating our expression traversal to include *ast.Field and
*ast.FieldList.
Fixesgolang/go#50539
Change-Id: I6531c6a51aa402bd784778b8bedaa3dccee75af0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395678
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Different naming style for Vuln type is unnecessary.
And, we can safely assume that ID is not empty.
Change-Id: Ifd43b671c814796af0110bad05642187bb1ea655
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395677
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Usage: gopls vulncheck <package_pattern>
It prints json-encoded command.VulncheckResult in stdout.
Change-Id: I752b3f06d7c6b2c7de68bd1221283205955c383f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395676
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Iaad847631b9d5ee40558fcf9d51f4dfa99600e6b
GitHub-Last-Rev: 6fcb64f8d9a093e7bd949e5d28bd1176c27005c0
GitHub-Pull-Request: golang/tools#372
Reviewed-on: https://go-review.googlesource.com/c/tools/+/389595
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Avoid a panic when a directoryFilters entry is empty.
Fixesgolang/go#51843
Change-Id: I50948894ce60d83441c3fc698c2e7d80d1d2b50e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395675
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Make builtin hover consistent with signatureHelp by reusing the
BuiltinSignature function. To simplify this, just precompute the builtin
signature. In later CLs we can pre-compute all signatures and eliminate
the signatureSource indirection.
Fixesgolang/go#51811
Change-Id: I1babe64ba41f636bf455074a23ad6dac5539fb89
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395294
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This is a command that runs govulncheck-like analysis.
This is highly experimental and can change any time,
so we mark it with the "Exp" suffix. Once the interface
becomes stable, we will rename this command.
It returns VulncheckResult that can be encoded as
a JSON message. The result includes all potentially
affecting vulnerabilities, and sample traces.
This feature is currently available only when gopls
is compiled with go1.18. Otherwise, the command will
return an error.
Updates golang/go#50577
Updates golang/vscode-go#2096
Change-Id: Ia37b0555f7bf98760292c9f68e50fb70dd494522
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395576
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
And move types defined in gopls/internal/vulncheck
to internal/lsp/command so VulncheckResult can use them.
Another approach considered is to encode Vuln as a
json raw message. However, presenting the data structure
in gopls api documentation is too nice to give up.
Updates golang/vscode-go#2096
Updates golang/go#50577
Change-Id: I8587d19f9c47cf786dacaae8cfe1727c77cda711
Reviewed-on: https://go-review.googlesource.com/c/tools/+/395575
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make the change from CL 334209 in the source.
Change-Id: I923d857b77552d6c8d100ce97b6b86f29fbc4934
Reviewed-on: https://go-review.googlesource.com/c/tools/+/393857
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
For example:
func foo[A int | float64](a A) A { return a }
var _ int = fo<>
Previously at <> we would complete to "int(foo[A int|float64](a A))".
We added the int() type conversion because the returned type param A
was convertible to the expected "int" (i.e. both "int" and "float64"
can be converted). This is a premature suggestion, though, so fix by
suppressing such type conversions for type parameters.
Fixesgolang/go#51780.
Change-Id: I63e3bd401a4d9927b9261659812c521c02e33d94
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394016
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
In this example:
func foo[A []int | []float64]() {}
foo[<>]
When completing at <> you were getting the creative candidate
"[]int | []float64". This came from some code that makes the expected
type available as a candidate if it wouldn't otherwise be found by a
lexical search. I tweaked the code in this case to instead look at
each structural type in the type constraint rather than the constraint
as a whole. In the above example you now get the candidates "[]int"
and "[]float64".
Change-Id: Ib8e422df3009cb4253ec66005b4a53851564c4e1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394015
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Now when instantiating a generic function, we prefer type names that
are assignable to the corresponding constraint. For example:
func foo[A int|string]() {}
foo[<>]()
At <> we prefer the type names "int" and "string". Previously we had
no preference at all.
Updates golang/go#51782.
Change-Id: I7ed39ffa2bc4c63e9d320f47a58e139251712bb3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394014
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Robert Findley
Hana
Suzy Mueller
Alan Donovan
Muir Manders
Dylan Le
Michael Matloob
Bryan C. Mills
Russ Cox
pjw
Dan Kortschak
Pontus Leitzler
hiroebe
Charlie Vieth
cuishuang