When parse errors occur, go's parse package cannot recover nicely.
gopls tried to compute folding ranges based on the partial info
in this case, but returning partial folding range info confuses
editors (vscode) and results in dropping previous folding range
info from the region after the parse error location.
This CL makes gopls not to return anything - so the editor can
tell the result is not believable and ignore it.
The ideal solution is to return a response explicitly surfacing
this case, but currently LSP (3.16, as of today) does not have
a way to describe this condition. See the discussion in
https://github.com/microsoft/language-server-protocol/issues/1200.
We also tried to make gopls return an error. While it worked
nicely in VSCode, we are not sure about how other editors handle
errors from foldingRange. So, instead, we just let gopls return
an empty result - since foldingRange is already broken in this
case, we hope it doesn't add a lot of noise to existing users.
VSCode Go will check the response from the middleware. If the
response is empty but the file is not empty, VSCode Go will
ignore the response.
(https://go-review.googlesource.com/c/vscode-go/+/299569)
Updates golang/vscode-go#1224
Updates golang/go#41281
Change-Id: I917d6667508aabbca1906137eb5e21a97a6cfdaf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291569
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The logic to extract the receiver identifier from a func decl was
incorrect, accepting only the common T and *T syntaxes, and panicking on
*(T).
Fix this by copying the logic from go/types.
Fixesgolang/go#44806
Change-Id: I1c87ab21ac04e484972bc4161180ca1112df3c73
Reviewed-on: https://go-review.googlesource.com/c/tools/+/298852
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>
The current hover information for constant time.Duration is not very
useful because it displays nanoseconds. So, show formatted duration
as an inline comment.
Fixesgolang/go#44667
Change-Id: I6177455fb8932d1914d5cf623c0d9c4eff8f0b3f
GitHub-Last-Rev: e168968012741a1e614c66bc97fe60b196943ed3
GitHub-Pull-Request: golang/tools#281
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297310
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For index expressions, optional "make" args, and composite literal
slice/array keys, we were inferring an expected type of int instead of
untyped int. This caused candidate rankings to not be quite right in
general, and in particular, after support for automatic type
conversions was added, the issue manifested as:
var foo []int
var bar int32
foo[ba<>] // completed to "int(bar)" instead of "bar"
Fixesgolang/go#43375.
Change-Id: I6daef7d23b767f296bdbbc8f47f5b2c972ad9b80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289272
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
In cases like:
type foo struct { a int; b float64 }
foo{b<>}
We were completing to "foo{int(b: <float64>)}" (the problem being the
nonsensical int() conversion).
The expected type at "<>" is int to allow completions to match "a".
When we pass the *types.Var representing "b" through the candidate
matching machinery, we say "Oh, a float64! I can convert that to my
expected type of int!".
Fix by bailing out of candidate matching early if the candidate is a
composite literal struct field name. Field names aren't really objects
you can do anything to.
Fixesgolang/go#43789.
Change-Id: Ie4dab166973dfcdcb519f864532ead1f792d25a3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289130
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
In cases like:
foo<> == 100
We weren't preferring floats at <>. Fix the basic type comparison
logic to know that an untyped int is always compatible with a float.
Fixesgolang/go#44066.
Change-Id: I9cf9bac1632178db100c0a5447351be208b4a2af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289129
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
Field embedding links two objects (a TypeName and a Var) by name,
requiring special handling during renaming. In CL 282932, renaming of
types was made to propagate to uses of their embeddings. However, no
such propagation in the reverse direction was added, meaning that
renaming an embedded field would not rename the corresponding type, and
code could still be left in a non-compiling state.
It should be an invariant that renaming does not change program
behavior. To enforce with field embeddings this we'd need to also rename
the corresponding type, but this seems problematic. If I'm hovering over
the field selector x.T, and rename T, it is surprising that this would
end up renaming a type.
For lack of a better solution, make it an error to rename embedded
fields, but try to provide a helpful error message.
Also handle the blank identifier, for which renaming was giving a
message to "please file a bug".
Marker tests are added for the new errors in rename, but not for
prepareRename. The prepareRename tests were not set up for asserting on
errors -- perhaps that would be a good project for a later CL where we
clean up errors.
Fixesgolang/go#43616
Change-Id: I66c2dd5e531dd102431d1edd443d553687d9ca7e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284312
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: 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 renaming a type name, also rename indirect uses of the name as an
embedded field. This is conservatively isolated to just renames for now;
it's not clear to me that users would also want to see uses of embedded
fields as references.
Fixesgolang/go#43616
Change-Id: I41913d037fedb8c27a448cd922eeaf11a02d01f1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282932
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Outgoing callhierarchy didn't handle different functions defined as
field in a struct as separate functions since they were declared by the
same AST node.
This change adds the identifier name to the key, so that a function
must share both declaration node and name to be considered "the same".
Fixesgolang/go#43456
Change-Id: Ifbced98f2e8fc3a303834f7cefbae66829b68d27
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280618
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When trying to get outgoing call hierarchy from an var func like:
func main() {
foo := func() {}
foo()
}
gopls crashed with a panic.
This change makes it return an empty call hierarchy instead.
It also adds support for testing outgoing calls where the expected
result is 0 items, to be able to test this change.
Fixesgolang/go#43376
Change-Id: Icd91bf54cb4fbd5203f5865f0ff9d81365c27d5d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279469
Trust: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When generating a default param name based on a type name, we want to
ignore any package qualifier. For example, if the type is "ast.Node"
we want to generate the variable name "n", so we must ignore the
"ast." qualifier. To do this we use a types.Qualifier that always
returns empty, but qualifyExpr wasn't respecting an empty qualifier
because it is doing manual ast manipulation. However, it seems like
things "just work" if you set a SelectorExpr's "X" to empty
string (i.e. only "Sel" is output when formatting).
Fixesgolang/go#42794.
Change-Id: Ied86b9511e4a9550590417c5a506fe35d561d4f9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275519
Run-TryBot: Muir Manders <muir@mnd.rs>
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: Robert Findley <rfindley@google.com>
In Go 1.16 error codes as well as start and end positions are added for
go/types errors. This information is temporarily stored in unexported
fields, until we're more confident in the correctness of both the API
and the underlying data.
Read this information using reflection and, if available, use it to set
the corresponding field in compiler diagnostics. This establishes a
positive feedback loop: in most cases this should improve the gopls
diagnostic, and wherever it doesn't we can make a note and fall back on
the old heuristics for that error code.
For golang/go#42290
Change-Id: I37475189cbd14a0a5bcfde163f599c9a7b957372
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268539
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I39d367d0731ea5b7b7bb963699be3003b4fefe86
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274119
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This updates fillstruct to work even when the struct is partially
filled. User supplied fields are preserved but comments are blown away.
Preserving comments appears to be very hard with the current ast
library. One possible option is to do manual string shenanigans, but
after exploring that path it seems like A Bad Idea.
Fixesgolang/go#39804
Change-Id: Iec0bb93db05d4d726dfa6c77a8139f53b14bcc77
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262018
Run-TryBot: Jean de Klerk <deklerk@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Jean de Klerk <deklerk@google.com>
For example:
func wantsInt64(int64) {}
func wantsDuration(time.Duration) {}
func _() {
for i := range []string{} {
// inserts "i" as "int64(i)"
wantsInt64(i<>)
// inserts "i" as "time.Duration(i)"
wantsDuration(i<>)
}
}
Type converted candidates have a significant score penalty so they
should never outrank a directly assignable candidate, other factors
being equal.
To minimize false positive completions, we don't offer converted
candidates if either:
- The candidate is a deep completion into another package. This avoids
random "float64(somepkg.SomeVar)" popping up when completing a
float64.
- Don't offer to convert ints to strings since that's not normally
what the user wants.
After going back and forth I decided not to include the type
conversion in the candidate label. This means you will just see the
candidate "i" in the completion popup instead of "float64(i)". Type
names add a lot of noise to the candidate list.
I also tweaked the untyped constant penalty to interplay better with
the new type conversion penalty. I wanted untyped constants to be
ranked above type conversion candidates since they are directly
assignable, so I reduced untyped constants' penalty. However, to
continue suppressing untyped constants from random other packages, I
applied a similar heuristic to above where we give a bigger penalty if
the untyped constant is a deep completion from another package.
Fixesgolang/go#42764.
Updates golang/go#39207 (untyped constant penalty tweak may improve
this situation).
Change-Id: I565114b3a1c9628285d07200b9dfc45c61e5d898
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272286
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: 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>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I888b33804eec7f38c329ae2e4343b82fcc22f1df
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272166
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>
The workspace symbol tests are not really resilient to changes and
did not generate/use golden files consistently. This made it really
tricky to switch the workspace symbols defaults.
To improve the workflow, consolidate the different kinds of tests into
one function, generate and use golden files, and require that all of the
workspace symbol queries appear in one file only. Also converted the
brittle workspace symbol regtest to a marker test.
Update golang/go#41760
Change-Id: I41ccd3ae58ae08fea717c7d8e9a2a10330e8c14f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271626
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>
There was a bug and inconsistency in how const identifiers were
categorized when being used. The new code always makes them readonly
variables.
The predeclared identifiers (true, false, nil, iota) were treated
inconsistently. The new code makes them all readonly variables.
Under rare conditions the output from gopls semtok was not syntactic
Go code because is would put a /* comment immediately after an
operator /, thereby generating a spurious line comment.
Fixesgolang/go#42715
Change-Id: I5b1ccfaf607d6baa58c132e460c5617db6634a72
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272208
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
These tests require special cases and are difficult to understand in the
marker format. They are much simpler as regression tests.
Fixesgolang/go#40332
Change-Id: I791b9092d0f3d08aa5415eced427850626f8eb2a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272207
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In
type myAlias = someType
type _ struct {
myAlias
}
Previously running "definition" on the "myAlias" field would take you
to the definition of "someType" instead of "myAlias". This is because
we were using the field's (*types.Var).Type() which has already
forgotten it is an alias. Fix by instead looking up the field name
ident in types.Info.Uses which yields the *types.TypeName (for the
type alias).
Fixesgolang/go#42254.
Change-Id: Idbbd0c49ba6f701f52568b3ab1143d8e24037c69
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272186
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Muir Manders <muir@mnd.rs>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
This extra query needs to be added before any link anchors (#), so it's
a little more complicated to add than expected. Separating out the
anchor from the link path simplifies the code a little bit and allows
us to create the correct links.
Fixesgolang/go#42602
Change-Id: Ia72d50e20b1446149f1ddd36b12f6d968a9b06cb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/270097
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>
The command 'gopls semtok <file>.go' produces a version of <file>.go
decorated with comments describing tokens as semantic tokens. The
format is described towards the top of cmd/semantictokens.go.
There are also tests in testdata/semantic/. a.go is used by lsp_test.go
(with -cover) to show that essentially all of semantic.go is executed.
b.go illustrates the handling of strange, but legal, constructs
like 'const false = nil and non-ascii'. The .golden files show
the expected results.
The implementation will panic, rather than log, on unexpected state.
gopls semtok has been run on all the .go files in x/tools and in
the source distribution. There were no unexpected messages nor panics.
Change-Id: I11715bcc8d6830d1951eb58239978c4a363bbc30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262198
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>
This change adds ability to show references to interface methods.
Instead of just showing direct references to a type, we also show
references to the type through an interface now.
Change-Id: I9d313b3b77c75adb9971dc56ee86caa697d03c90
Reviewed-on: https://go-review.googlesource.com/c/tools/+/259998
Trust: Danish Dua <danishdua@google.com>
Run-TryBot: Danish Dua <danishdua@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change eliminates any special scenarios where we need to call
c.item instead of going through deepSearch by adding support for all the
cases in deepSearch and c.addItem (previously c.item).
Change-Id: Ifb250be54da2f8c7b656475fcafaa38a4e306244
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258858
Run-TryBot: Danish Dua <danishdua@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Danish Dua <danishdua@google.com>
The percent package has an invalid import path and a disallowed
character in a source file. In CL 258298, I am changing cmd/go to
diagnose invalid import paths during loading (instead of during
missing-import resolution), and as a result 'go list' will no longer
attempt to load or enumerate the source files for that package.
It is important that gopls and 'go list' not crash when attempting to
load a package with an invalid path, but gopls should not assume that
'go list' will produce anything more than an error for it.
For golang/go#37438
For golang/go#41576
Change-Id: I8af8896ea7108f1588e0085ddc1bf1b9ff55d5b9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258717
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: Heschi Kreinick <heschi@google.com>
Mostly a rollback of CL 217541. No changes in the actual tests.
Change-Id: I910551d4750822bd2d8c5039d1cf194e42d01500
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256363
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>
As we begin testing multi-module workspace, clean up existing
multi-module marker tests. Most of their coverage was redundant with reg
tests already. Add a couple to cover the remainder.
This is probably not strictly necessary but it was easier to remove the
tests than worry about how to support them in multi-module mode.
Change-Id: I54cca5eea60e0679759f7d39131c5cd015fb0154
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256361
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>
This change improves the labels for import suggestions to only show the
last part of the path. Since VSCode fuzzy searches for labels in text
edit, we now return only the last part of path as text edit instead of
replacing the full import path. Just changing label while returning full
path leads to bad user experience.
Closesgolang/go#35877
Change-Id: Ib10e7a3e030dc9b850ff1d9ec8d45240b75b64a3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/255837
Run-TryBot: Danish Dua <danishdua@google.com>
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: Danish Dua <danishdua@google.com>
Broke a.go into a few files (no real logic to it). These tests could be
categorized better, but it's a good start just to break up that huge
golden file.
Change-Id: I2c173f11ea2766e9232e3ec838c16f535cbee788
Reviewed-on: https://go-review.googlesource.com/c/tools/+/253279
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL creates a struct that simplifies some of the extract function
logic. Also, add a test for extraction with an underscore in the
selection (Josh mentioned that this might not work, but it seems too).
Change-Id: If917614a5824e84fb79a07def3eb75f48f10a5b9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/253277
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Refactor the checks for code lenses being enabled out of the source
package so that the mod code lenses can also make use of them.
Also, a few small changes to the titles of the `go mod tidy` and `go mod
vendor` code lenses.
Change-Id: I4e79ab08a4e7aea4d4d6de6fd652d0b77d30c811
Reviewed-on: https://go-review.googlesource.com/c/tools/+/252397
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is based on Paul Jolly's CL 228760, updated to use the new cache
API, support the symbolStyle configuration option, and lift up the
concept of symbol score for later improvement.
From that CL:
There are a number of issues with the current implementation:
* test variant packages are not handled correctly, meaning duplicate
symbols are returned
* fuzzy results are not ordered by score
We refactor the implementation of workspace symbol to use a
symbolCollector that carries context during the walk for symbols. As
part of resolving the test variant issue, we first determine a list of
packages to walk.
(*symbolCollector).collectPackages gathers the packages we are going to
inspect for symbols. This pre-step is required in order to filter out
any "duplicate" *types.Package. The duplicates arise for packages that
have test variants. For example, if package mod.com/p has test files,
then we will visit two packages that have the PkgPath() mod.com/p: the
first is the actual package mod.com/p, the second is a special version
that includes the non-XTest _test.go files. If we were to walk both of
of these packages, then we would get duplicate matching symbols and we
would waste effort. Therefore where test variants exist we walk those
(because they include any symbols defined in non-XTest _test.go files).
One further complication is that even after this filtering, packages
between views might not be "identical" because they can be built using
different build constraints (via the "env" config option). Therefore on
a per view basis we first build up a map of PkgPath() -> *types.Package
preferring the test variants if they exist. Then we merge the results
between views, de-duping by *types.Package.
Finally, when we come to walk these packages and start gathering
symbols, we ignore any files we have already seen (due to different
*types.Package for the same import path as a result of different build
constraints), keeping track of those symbols via symbolCollector.
Then we walk that list of packages in much the same way as before.
For golang/go#40548
Co-authored-by: Paul Jolly <paul@myitcv.io>
Change-Id: I8af5bdedbd4a6c3631a213d73a735aea556a13ae
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247818
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds completion within import blocks. Completions are suggested by directory depth of import so end user isn't shown a large list of possible imports at once. As an example, searching import for prefix "golang" would suggest "golang.org/" and then subdirectories under that (ex: "golang.org/x/"") on successive completion request and so on until a complete package path is selected.
Change-Id: I962d32f2b7eef2c6b2ce8dc8a326ea34c726aa36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250301
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Seems we've drifted a bit from go1.12 support, mostly due to error
wrapping.
Fix this, as well as some assorted other failures.
I haven't tested 1.12 interactively.
For golang/go#39146
Change-Id: Id347ead2a13e89b76d2ae0047750e6b6b49911eb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250941
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Fillstruct wasn't able to fill structs with fileds that held anonymous
structs or maps with anonymous structs/interfaces.
By adding *types.Struct and *types.Interface support in TypeExpr(),
fillstruct is now works for those as well.
Fixesgolang/go#40980
Change-Id: I2a1d6d4db237800197cf14e3ad5067a0e7ab701a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249999
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* adds support for comment completion inside declarations
* improves scoring for completion results for comments
* adds comment completion support for non-exported symbols
* adds pruning for results that don't match text surrounding cursor
* tests for comment completion
Change-Id: Icb445a469cee3122fe032630bee037c7bdfe2e18
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249639
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Fix completion in the following cases:
type foo struct{}
// now we offer "&foo" instead of "foo"
var _ *foo = fo<>{}
struct { f *foo }{
// now we offer "&foo" instead of "*foo"
f: fo<>{},
}
Composite literal type names are a bit special because they are part
of an arbitrary value expression rather than just a standalone type
name expression. In particular, they can be preceded by "&", which
affects how they relate to the surrounding context. The "&" doesn't
technically apply to the type name, but we must take it into account.
I made three changes to fix the behavior:
1. When we want to make a composite literal type name into a pointer,
we use "&" instead of "*".
2. Record if a composite literal type is already has a "&" so we don't
add it again.
3. Fix "var _ *foo = fo<>{}" to properly infer expected type of "*foo"
by not stopping at *ast.CompositeLit searching up AST path when the
position is in the type name (as opposed to within the curlies).
Change-Id: Iee828f259eb939646b68f5066614ea3a262585c2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247525
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We now rank printf operand candidates according to the corresponding
formatting verb. We follow what fmt allows for the most part, but I
omitted some things because they are uncommon and would result in many
false positives, or didn't seem worth it to support:
- We don't prefer fmt.Stringer or error types for "%x" or "%X".
- We don't prefer pointers for any verbs except "%p".
- We don't prefer recursive application of verbs (e.g. we won't prefer
[]string for "%s").
I decided against sharing code with the printf analyzer. It was
tangled somewhat with go/analysis, and I needed only a very small
subset of the format parsing.
I tweaked candidate type evaluation to accommodate the printf hints.
We now skip expected type of "interface{}" when matching candidate
types because it matches everything and would always supersede the
coarser object kind checks.
Fixesgolang/go#40485.
Change-Id: I6440702e33d5ec85d701f8be65453044b5dab746
Reviewed-on: https://go-review.googlesource.com/c/tools/+/246699
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
* Adds outgoing calls call hierarchy for function declarations to gopls. Returns all call ranges and call items for functions/literals being called.
* Adds tests for outgoing call.
* Updates cmd to account for call ranges and call items being in different files for outgoing calls.
* Updates prepare call hierarchy to return declaration as root instead of cursor position.
Example:
Example shows https://github.com/golang/tools/blob/master/internal/lsp/source/call_hierarchy.go
Show Call Hierarchy View: https://imgur.com/a/DA5vc6l
Peek Call Hierarchy View: https://imgur.com/a/fuiG0Be
Note:
* While incoming calls for a function defined in an interface return references to that function, outgoing calls don't return anything since we don't know what implementation to return outgoing calls for.* Outgoing calls to function literals show as variable name used to define the literal, compared to <scope>.func() for incoming calls.
Change-Id: Ib8afbd8617675d12952db0b80170ada5988e90ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248537
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
go mod tidy lens only shows up for a dirty mod file. Tidying a dirty
mod file makes the lens disappear.
Closesgolang/go#40422
Change-Id: I3356ffe94deaf7a5cdfc159c16470894336edf9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248717
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In this example:
p := &[]int{}
append([]int{}, *<>)
At <> we completed to "**p" instead of "*p...". There were two fixes:
1. builtinArgType() wasn't propagating the "modifiers", so we were
forgetting about the preceding "*" pointer indirection and
inserting it again with the completion. Fix by propagating
modifiers.
2. The candidate formatting responsible for adding "..." had over
simplified logic to determine if we are completing the variadic
param. Now instead the candidate evaluation code marks the
candidate as "variadic" so the formatting doesn't have to think at
all.
Change-Id: Ib71ee8ecfafb915df331f1d2e55b76f76a530243
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248018
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In the following example:
var foo []someStruct
foo = append(foo, <>)
we now downrank "foo" as a candidate at "<>". You very rarely append a
slice to itself, so having "foo" ranked highly was counterproductive.
Fixesgolang/go#40535.
Change-Id: Ic01366aeded4ba2b6b64bfddd33415499b35a323
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247519
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Hana
Rob Findley
Shoshin Nikita
Muir Manders
Pontus Leitzler
Rebecca Stambler
Jean de Klerk
Peter Weinbergr
Danish Dua
Bryan C. Mills
Heschi Kreinick
