The comparable interface is introduced on the dev.typeparams branch.
Filter it out from gopls completion results so that it doesn't break
tests on the dev.typeparams branch.
Change-Id: Iba22c0980c09e99b454ce9e22813cc3a1f94a90c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293931
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
Autocompleting a import without quotes appends to the completion,
producing this result: `import math "math/"`.
This commit changes to skip completions when typing a import without
quotes, because the users can be typing the alias of the import.
Fixes: golang/go#42748
Change-Id: I7050989f1f90a6720c17f71f338e50fad1f01456
GitHub-Last-Rev: e7b189a04acd8e501d6d7ac944d25de19156d0da
GitHub-Pull-Request: golang/tools#263
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280652
Reviewed-by: 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>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Rebecca Stambler <rstambler@golang.org>
When -mod=readonly and GOPROXY=off are set, the newly imported package
is not type-checked with the new import until it is reflected in the
go.mod file. In such cases, we can continue treating the package as
unimported and get symbols through unimported completions.
Fixesgolang/go#43339
Change-Id: I864c2c6738b537093c0670a266e9030af33f2d36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280095
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>
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>
Previously struct fields completions are ordered alphabetically.
Now it is ordered by its order in definition.
Fixesgolang/go#42626
Change-Id: I8c404205b97fa9f1a5a66a95a84033b6f0f48eae
Reviewed-on: https://go-review.googlesource.com/c/tools/+/270777
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: Robert Findley <rfindley@google.com>
It felt a little redundant to have completion duplicated in the file
names. Happy to revert if you prefer it the original way.
Change-Id: Ibf14a739688d48ecce0b86154b3cbe4807b2f8b1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/266477
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>
I had originally wanted to create a shared code path for hover in all
cases, but hover has a lot more differences from the documentation in
signature help and completion than I expected. You can't use markdown,
and you probably don't want links--it would take a bigger refactor to
extract something that worked for each feature.
Handling the Structured and SingleLine hover setting also doesn't seem
necessary--those settings are really specific to the way the client
presents the hover, which isn't related to signature help or completion.
For completion, all we need is an extra check on the hover kind for the
NoDocumentation option.
Fixesgolang/go#38577
Change-Id: Ib2037906c13f5be26813fcd2c20989e4d1b6c9bd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/266139
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Noticed these when I enabled the "unusedparams" analyzer. Not really
necessary to fix most of them, but seemed harmless.
Change-Id: I77c6e5f7c79f1abb701cd3332642486c34049736
Reviewed-on: https://go-review.googlesource.com/c/tools/+/263203
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>
Type-checking can be very expensive for large packages and leave no
budget for shallow completions. This change adds a minimum budget of
10ms so we show the user at least some shallow suggestions.
Updates golang/go#41434
Change-Id: If2ef59c3fbdcfa2ebaabb21256cf606a4f9c14d6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262347
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 changes bumps relevance for modules with major versions >1 so the
results for unimported members are ordered by major version.
Updates golang/go#41800
Change-Id: I64f4a1cf78a101acf4229433d06b5793246962f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/261084
Run-TryBot: Danish Dua <danishdua@google.com>
Trust: Danish Dua <danishdua@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Workspace packages seem to contain an empty package name when no
package is present, we can just ignore it since it leads to an
irrelevant completion suggestion.
Fixesgolang/go#41746
Change-Id: I4820751ad0f741dd0d29b42485b41bb4c296a169
Reviewed-on: https://go-review.googlesource.com/c/tools/+/259217
Run-TryBot: Danish Dua <danishdua@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Danish Dua <danishdua@google.com>
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>
This change adds calls to c.matcher.score for commment completion so
comments match the prefix (or fuzzy match depending on user settings)
and don't end up giving the user too many irrelevant suggestions.
Change-Id: Ie660f82c491c17d52e68e781a812bf8053e501f8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258322
Trust: Danish Dua <danishdua@google.com>
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>
This change removes contexts from functions that don't use them. Passing
down context unnecessarily leads to us having to propagate them
everywhere.
Change-Id: I1723721faf4f487b6cc92b9daef3f23747d9cbc1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258285
Trust: Danish Dua <danishdua@google.com>
Run-TryBot: Danish Dua <danishdua@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Unimported completions are expensive and can use up a large portion of
completion budget just to find initial deep search candidates. This
change moves these expensive operations which search through the module
cache to after normal deep completions so we search through more useful
candidates first.
Fixesgolang/go#41434Fixesgolang/go#41665
Change-Id: I6f3963f8c65c1a97833a35738d2e96420de2f6ee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/257974
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>
This change switches over load and RunProcessEnvFunc to use the
snapshot's modules instead of the view's modURI. These do not seem to
have been the racy parts of CL 257417.
Change-Id: I317a350fc4b0c62d77858455a0e2e61148804ecd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/257969
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>
This change moves package selection to before type checking so we don't
unnecessarily type-check both variants of a package. As a result, exec
time and memory usage for features making calls to GetParsedFile are cut
by half since we only type check either the narrowest or the widest
package.
Change-Id: Ifd076f8c38e33de2bd3509fe17feafccd59d7419
Reviewed-on: https://go-review.googlesource.com/c/tools/+/257240
Run-TryBot: Danish Dua <danishdua@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Danish Dua <danishdua@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change refactors deep completion to move search path to a candidate
instead of pointing to it in search queue. This removes the idea of
"being in deep completion" and instead a deep candidate is just a
candidate with a path from search root.
Change-Id: Iec6a0f4409c0c8793986d5c1063000205ed43477
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256417
Run-TryBot: Danish Dua <danishdua@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Danish Dua <danishdua@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Currently, we deep search top level candidates as soon as they're found,
which isn't necessarily leading to an overall breadth first search
approach. This change refactors completion to add candidates to search
queue instead and only call deepSearch once at the end.
Change-Id: I712b03c98b57680a1f1c95df2385f7f2ea6e1ed0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256259
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>
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>
This change converts deep completion from depth first search to breadth
first search.
Change-Id: Iebc7ba8d3acb44928220596065d4e8de53ea9b48
Reviewed-on: https://go-review.googlesource.com/c/tools/+/254542
Run-TryBot: Danish Dua <danishdua@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Danish Dua <danishdua@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
I have no idea what I did to trigger this, but I got a panic in this
codepath. Since this is for completion, it should be OK to simply make
this code defensive, without fully understanding the cause.
Here's the panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xc570f3]
goroutine 5914644 [running]:
golang.org/x/tools/internal/lsp/source/completion.(*completer).addFieldItems(0xc0996ee240, 0x1032020, 0xc0dd21e2a0, 0xc0b99b26f0)
/usr/local/google/home/rfindley/src/tools/internal/lsp/source/completion/completion.go:1065 +0x193
Change-Id: I82350b30172ead95b6611962c2e040cc49259dc2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/254697
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>
gopls has many settings. We want to automatically generate
documentation, and we want to allow clients to perform their own
validation if they so desire.
Using all three of AST, type information, and reflection, generate a
JSON description of the settings and their default values. Add a gopls
command that prints it. Add a documentation generator that uses it to
write settings.md.
I assumed that everything not explicitly documented was experimental,
and moved it into that section. I also moved expandWorkspaceToModule to
experimental; I hope it's not long for this world, personally.
Along the way, rename many fields, make the enum matching case
insensitive, and add a stringer call so that the defaults print nicely.
Fixesgolang/go#33544.
Change-Id: Ibb652002933e355ed3c6038d6ca48345b39b3025
Reviewed-on: https://go-review.googlesource.com/c/tools/+/252322
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds one more test for package completions (and slightly
modifies the way we pass in file content without a terminal newline).
Also, a few tiny modifications to the package completion code.
Change-Id: I3041b5ad648873881b2b8df17df6f78fbd1898e5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/253177
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Danish Dua <danishdua@google.com>
Completion is slowly becoming a large part of internal/lsp/source and it
makes sense to move to its own seperate package inside source to make
future refactors easier. As a part of this change, any unexported
members from source required by completion are now exported. Util
functions only required by completion are moved from
internal/lsp/source/util.go to internal/lsp/source/completion/util.go.
Change-Id: I6b7405ec598c910545e649bb0e6aa02ffa653b38
Reviewed-on: https://go-review.googlesource.com/c/tools/+/253178
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>