Enable to hover runes found in basic literals in various forms.
When a rune is found, the hover message provides a summary composed of a
printable version (if it exists) of the rune, its codepoint and its name.
Behaviour varies slightly depending on the basic literal: rune literals
always display the summary when hovered, string literals only display it
when an escaped rune sequence is found to avoid providing unnecessary
information, and finally number literals only when expressed as a
hexadecimal number whose size ranges from one to eight bytes.
Fixesgolang/go#38239
Change-Id: I024fdd5c511a45c7c285e200ce1eda0669a45491
Reviewed-on: https://go-review.googlesource.com/c/tools/+/321810
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The suggesteds completions are based on a superficial parse of all
the template files in the package. The code errs on the side of too
many suggestions.
Change-Id: If956ad548327be25517878aab70802cf62d42a50
Reviewed-on: https://go-review.googlesource.com/c/tools/+/341649
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: 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>
As per the current specification, the correct token name that represents methods is `method`. The current implementation does not produce the correct set of result and results in methods being incorrectly highlighted. Furthermore, the parameter names of interface methods are treated as `method` which is not true, so a fix has been applied to handle `ast.FuncType` being `parameter`.
Spec: https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_semanticTokens
Change-Id: Id5d2fafe9f948a4a175ae19b4c94cca8f48a4b79
GitHub-Last-Rev: 9a3b65ca4dd3bb0542969c043a2042001c7fcb63
GitHub-Pull-Request: golang/tools#340
Reviewed-on: https://go-review.googlesource.com/c/tools/+/349449
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
This shows up every now and then--maybe we need a wrapper function
around token.Offset to check the range.
Updates golang/go#48249
Change-Id: I9c60bc7cc61fcfb2f4e8c6963586d8b8fbb21835
Reviewed-on: https://go-review.googlesource.com/c/tools/+/348429
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>
When resolving a position to a package we must consider all packages,
including intermediate test variants. This manifests, for example, when
jumping to definition in a package that is imported as a test variant
(see golang/go#47825).
For now, fix this by threading through an 'includeTestVariants' flag to
PackagesForFile. This isn't pretty, but should be a trivially safe
change: the only effect will be to increase the number of packages
considered in FindPackageFromPos. Since we are discussing future changes
to the API for querying packages from the snapshot, now did not seem
like a good time to undertake significant refactoring.
A regtest based on the original issue is included.
This CL is joint with rstambler@golang.org.
Fixesgolang/go#47825
Co-authored-by: Rebecca Stambler <rstambler@golang.org>
Change-Id: I4693ec69b50ed4acd569cff87883769c1edf332b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/347563
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 use a case-insensitive comparison so this doesn't really
matter but it's a bit confusing that gopls/doc/settings.md and
internal/lsp/source/api_json.go were inconsistent here. I'm assuming
the latter also shows up as user-visible documentation somewhere,
probably in the VSCode plugin.
Change-Id: I14fa5b9d062266b6de0397aafb36e0ad84730752
Reviewed-on: https://go-review.googlesource.com/c/tools/+/344353
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>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
There is a TODO to remove the "codelens" alias. This updates an
example in the documentation to use the new name.
Change-Id: Id807e99f5ba1da663eae9660fb65521596b0c488
Reviewed-on: https://go-review.googlesource.com/c/tools/+/344352
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
It is unlikely that users want gopls operating on their node_modules
directories, so we should exclude them by default. If a user wants to
include them, they can override their directory filters setting.
This doesn't exclude *any* directory named "node_modules", so we still
need to implement golang/go#46438 to exclude node_modules completely.
Change-Id: I03c42208e62390dc35e44ac5176422ddf8dc53f7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/347297
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For
import "a/bar/foo"
the existing code just decides the last component is the package name.
But for
import "a/bar/v2" this is incorrect, as the packge name is 'bar'.
The new code uses the result of parsing to derive the package name
from the import string.
That is, the package name was determined syntactically, it is
now determined semantically.
Fixes https://golang.org/issue/47784
Change-Id: Iccdd25e7e3f591e6514b1e0258e9e1879af9ff2d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/343909
Trust: Peter Weinberger <pjw@google.com>
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>
I'm not sure why there was a goroutine in the defer here, but I think
this should fix the flakiness of this test. I wasn't able to reproduce
the flake myself locally however, so I couldn't confirm. I'll leave the
issue open until it stops happening.
For golang/go#47508
Change-Id: Ie9fdc68d70fe1634c3ad001441cf3ce0d2693d17
Reviewed-on: https://go-review.googlesource.com/c/tools/+/342674
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>
When searching for references or renaming, we start from all packages
containing the current position. But as reported in golang/go#47564,
this fails if we're renaming an object in another package; we need to
start the search from the package containing the object definition.
This CL finds the missing packages by recursively searching all
locations we encounter. For now, this will cause us to consider the
object location, and may also help us behave correctly with respect to
build constraint variants in the future.
While at it, update the regtests to support renaming. This bug could
be exercised with marker tests, but it's good to have a regtest for
renaming anyway.
Fixesgolang/go#47564
Change-Id: I5517e2aeaaa744fcc6b6b96ffbb0b2625b498ed5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340472
Trust: Robert Findley <rfindley@google.com>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In preparation for moving metadata related functionality to a separate
package, move around some types and export some symbols. This is purely
to reduce diffs in subsequent CLs, and contains no functional changes.
Change-Id: I24d4fbd71df78e4d7a84f6598cdf820b41d542a2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340729
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>
This will allow us to add more support for the workspace proposal.
Change-Id: Ie557121afe0c16989ac176dc9246d82661a20c44
Reviewed-on: https://go-review.googlesource.com/c/tools/+/341811
Trust: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The predeclared 'any' type is only valid when completing constraints. We
should support that properly, but for now exclude it from results so
that our completion tests don't fail on Go 1.18.
For golang/go#47669
Change-Id: I7852f844684a6c03da90bf367d45d732e5d1e9bb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/341850
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: Matthew Dempsky <mdempsky@google.com>
Add the scope to the command-line-arguments package ID and path so that
multiple command-line-arguments packages can coexist in the workspace.
Fixesgolang/go#47584
Change-Id: Icbfe90d67627f384c54f352e46270ab2bf4240bd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/341611
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>
Tweak a few things to reduce garbage:
- Pre-allocate a couple hot error objects in format.go.
- Change methodsAndFields and packageMembers to take a callback
instead of returning a slice.
- Use two queues for breadth first search. This allows us to alternate
between and reuse the queues for each search level instead of
appending to a single queue indefinitely with no reuse.
- Get rid of candidate.names field. This tracked the string name of
each object in the deep completion path. Unlike with DFS before,
due to BFS this has to be copied for every candidate we inspect. Now
we get the object names from each types.Object in candidate.path,
with the addition of a new bitmask field to remember whether each
object needs "()" appended to it.
Using TestBenchmarkFuncDeepCompletion as a benchmark:
name old time/op new time/op delta
Statistics 14.2ms ± 7% 10.3ms ± 1% -27.41% (p=0.016 n=5+4)
name old alloc/op new alloc/op delta
Statistics 4.31MB ± 1% 3.03MB ± 0% -29.60% (p=0.016 n=5+4)
name old allocs/op new allocs/op delta
Statistics 52.7k ± 1% 44.0k ± 5% -16.52% (p=0.008 n=5+5)
Change-Id: I52f619d9a2e8553115be91f05cf8cc5cfa89123e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323252
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The lexicalLookup function is used to determine if
a use of an object would be shadowed by a different
definition after a rename. Switch to using LookupParent
which is more careful about the positions of the
identifiers.
Fixesgolang/go#47583
Change-Id: I3dbdf79e537ce637d1276ddbecb094db21f1c26d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340551
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
And add a case that can occur while the user is editing the file.
Fix Parsed.LineCol to get a usable answer for the final newline.
Change-Id: I6367ff52051d72431453525279d99d7eb2180703
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339772
Run-TryBot: 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>
Trust: Peter Weinberger <pjw@google.com>
Unfortunately only after merging CL 338729 did I use it in a multi-view
workspace. That CL added a goroutine per matcher to scan symbols, but
unfortunately did this for each view, resulting in a race if there are
multiple views.
The fix is straightforward.
Change-Id: I405b37921883f9617f17c1e1506ff67b4c661cbc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340970
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>
By refactoring the symbol resolution to defer symbol construction until
after scoring, we can avoid some unnecessary string allocation.
Benchmark (fastfuzzy "test" in x/tools): 21ms->17ms
Benchmark (fuzzy "test" in x/tools): 46ms->42ms
Benchmark (fastfuzzy "test" in kubernetes): 199ms->183ms
Change-Id: I9de72eb203c9971acc1afe89657976ce193b5a5d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338696
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>
Hook up the new fast SymbolMatcher as an option.
Benchmark ("test" in x/tools): 48ms->21ms (with the new matcher)
Benchmark ("test" in kubernetes): 857ms->199ms (with the new matcher)
Change-Id: Ic638eda1ed10572638f32879dd9b56467ae305ef
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338695
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>
For workspace symbol requests we use various workarounds to optimize
matches for Go symbol paths (specifically, to increase relevance toward
the right hand side of a symbol path). These workarounds have a
significant impact on performance.
The existing fuzzy matcher could also be optimized, but is hard to
modify safely. As an experiment, add a new simple-but-fast fuzzy matcher
to use as a point of reference.
Change-Id: Iacaf149dfaf75f25e13909145f9508c7eaedf1a2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338689
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: Peter Weinberger <pjw@google.com>
We can avoid allocating strings when performing workspace symbol search
by having the fuzzy match operate directly on chunks.
When operating on a single string, this slows down the matcher slightly
(perhaps 10%) due to copying bytes rather than accessing the string
directly. We could work around this using unsafe, but this could also be
mitigated by generics.
Benchmark ("test" in x/tools): 48ms->46ms
Benchmark ("test" in kubernetes): 868ms->857ms
Change-Id: Icf0f15aaa5cc3c875cf157a7b90db801045d9ed4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338694
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>
Whenever possible we should avoid doing string operations when computing
workspace symbols. This CL lays the groundwork for optimizations of this
sort by changing the signature of matcherFunc to accept chunks. It is
done in a naive way though, so this doesn't yet improve performance.
Benchmark ("test" in x/tools): 40ms->48ms
Benchmark ("test" in kubernetes): 799ms->868ms
Change-Id: I171c654b914e9764cfb16f14d65ef1aed797df73
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338693
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>
Coupling workspace symbols to package checking means that they do not
function when the workspace is contracted, and also forces us to do
duplicate work traversing file declarations.
This CL changes the workspace symbol implementation to precompute
symbols based only on syntactic information, allowing them to function
in degraded workspace mode, improving their performance, and laying the
groundwork for more significant performance improvement later on.
There is some loss of precision where we can't determine the kind of a
symbol from syntactic information alone, but this is minor: we fall back
on 'Class' if we can't determine whether a type definition is a basic
type, struct, or interface.
Benchmark ("test" in x/tools): 56ms->40ms
Benchmark ("test" in kuberneted): 874ms->799ms
Change-Id: Ic48df29b387bf029dd374d7d09720746bc27ae5e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338692
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>
Before this CL, we preferred less qualified symbols in the "dynamic"
symbol style by executing multiple matches from right to left. This is
significantly inefficient for only a marginal benefit over using the
match indexes produces by the fuzzy matcher.
Instead, change the signature of the matcherFunc to expose the matched
index to compute the dynamic symbol.
Benchmark ("test" in x/tools): 144ms->56ms
Benchmark ("test" in kubernetes): 2.6s->874ms
Change-Id: I0bf017feee436bc0d8b14bdda1e64fd227669dd7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338691
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>
ParseHeader mode is used to parse only the package and import declarations.
However, change of go:embed directive should also invalidate metadata.
So, we must use ParseFull mode to get all file comments to compare
old and new go:embed directives.
Fixesgolang/go#47436
Change-Id: If7cdb6741e895315bb6a6de2f207b404e15b269a
GitHub-Last-Rev: 64d606cead064ed5996eb7d55c3664940e7a1deb
GitHub-Pull-Request: golang/tools#333
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339469
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Fix connection error not being returned resulting in errors like `gopls: remote disconnected: <nil>`.
Change-Id: I67fa1143b2fa0fd44c946040fc1bad51b1636183
GitHub-Last-Rev: 9ebae5c3b85b7bb73eb67bb1ee8028f6f504a83d
GitHub-Pull-Request: golang/tools#334
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339709
Reviewed-by: 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>
Trust: Peter Weinberger <pjw@google.com>
No significant changes.
The only change is to CompletionItemLabelDetails, which is new in 3.17.
Change-Id: I172f0ff72f5c27c0907d7ad733f19a6320c5f510
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339089
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>
Template tokenization was handling quoting incorrectly.
(The previous code would misunderstand {{"{{"}}.)
While the user is typing an action in a template file the template
parser was returning a correct but useless error, so gopls had no
information about the file. The new code improves this by tokenizing
and parsing an adjusted version of the file. That is, it can sometimes
tell when the user has started typing an action so the {{, }} delimiters
are unbalanced. It replaces the new {{ by blanks, thereby suppressing
a lot of useless error messages from gopls.
Something like this seems to be a prerequisite for provdiding completions
based on the contents of the rest of the file.
Change-Id: I6b6396a4d9e599d671e778b303e6628642585a90
Reviewed-on: https://go-review.googlesource.com/c/tools/+/337351
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>
Recent changes to the go/ast APIs for type parameters have broken the
internal/typeparams package when built with -tags=typeparams.
Fix this by adjusting the internal/typeparams API. Also update a few
tests accordingly.
Bump the build constraint used by the internal/typeparams package to
go1.18, as we are no longer compatible with the 1.17 typeparams API. It
is no long possible to opt in to type parameter specific functionality
1.17, which is fine as the dev.typeparams branch has moved to 1.18.
Even after these fixes, not all x/tools tests pass with go1.18. Some
completion tests are failing due to finding 'any' in types.Universe.
Change-Id: I5f92870aaf7853e531e3a154987f98520a52d70c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339349
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>
Edits from the code action "extract variable" wasn't ordered.
The reason this wasn't picked up by the tests (and in fact, the test
failed when edits were in order) is that multiple edits to the same file
was sent as multiple "DocumentChanges" with a single edit each.
By updating ApplyFix() to consolidate edits to the same file into a
single DocumentChange with multiple edits, we avoid the undefined(?)
behaviour of how clients should handle multiple DocumentChanges to the
same file & version.
Fixesgolang/go#47486
Change-Id: Ie4a4718ceb40693b84c014f66c8fc0d221843d88
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338869
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>
Check that a position is in range before using it.
Fixesgolang/vscode-go#1656
Change-Id: I1598ebab76a1775afd8f63b9849049b31fb74a8b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339169
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: Peter Weinberger <pjw@google.com>
This logic was duplicated as part of the invalid metadata CL.
I believe the loop on L1873 is the intended behavior.
Change-Id: I93ceb3da4045f0536be7dc9da7cecc4323e14a92
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339112
Trust: Rebecca Stambler <rstambler@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 Findley <rfindley@google.com>
Previously, if the position was before the "." in a selector,
pathEnclosingObjNode would move the position to right after the
".". This created confusing behavior where editors would highlight
the identifier before the ".", but references and go to definition
would be applied on the identified after the selector. This change
removes the shifting of the position if found on a selector.
Fixesgolang/go#47408
Change-Id: If2504e7d5af2fae24b97c5c1e88b9cbe67aaaaf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338789
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>
In my testing, the gopls degraded memory mode (currently set via
"memoryMode": "DegradeClosed") did not save as much memory as expected
due to still type checking all packages in the workspace (even if in
ParseExported mode). It is also annoying to get incomplete results from
references and renaming.
I think we can (and should) fix both problems: don't even consider
packages that aren't 'reachable' via open files, but fully type check
the reverse transitive closure of the packages you're working on. This
CL does exactly that, by swapping out the concept of 'workspace
packages' with 'active packages'.
In testing, this decreased my memory footprint while working on std by
3-4x when compared to normal mode, and 2x when compared to the previous
implementation of DegradeClosed.
It still needs more testing before we move this option out of
experimental.
For golang/go#46902
Change-Id: I1e319d0b1607d344d27e797ce32de057d7a583f9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/336410
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 enriching identifier info with full syntax, it's cleaner to find
the enclosing decl. Use the full decl in hover if we were unable to find
a node in the original type-checked package.
Update the regtest to exercise hovering in a non-workspace package.
Updates golang/go#46158
Change-Id: Ic1772a38fb1758fb57a09da9483a8853cc5498f1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/333690
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>
Currently the `SignatureHelp` function provides signature help even when the
requested range lies within a string literal. Let's suppress this behavior and
return an error when someone requests signature help from within a string
literal.
Fixesgolang/go#43397
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Change-Id: Ib03e87258622f4294bf9385bf5f0a8effe0050ee
GitHub-Last-Rev: 0c9549ae68b0263a3cac274da133e9ab4b4c7bf5
GitHub-Pull-Request: golang/tools#332
Reviewed-on: https://go-review.googlesource.com/c/tools/+/337170
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
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>
We currently support evaluating int literals on hover
if it's a const declaration but not if it's a var. This
change adds support for the same for var.
Fixesgolang/go#45802
Change-Id: I3c4f6024b4b58fed38a5111253aa9e2ac30249fb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/330309
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>
"Extract method" allows users to take a code fragment and move it
to a separate method. This is available if the enclosing function
is a method.
Change-Id: Ib824f6b79b13ca73532223283a050946c90a47e7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/330070
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>
Fix the imports text edits by computing it on first principles. This
fixes at least a couple bugs:
- Incorrect handling of positions between \r and \n with windows line
endings.
- Incorrect computation of edits when the imports source prefix is
synthetically terminated with just \n, but the actual source has
\r\n.
This is an unsatisfying solution, necessary because of the interaction
of token.File with file termination (token.File does not capture this
information).
Efforts to fix token.File proved complicated, and this is causing
problems for our users, so I think we should do this for now.
For golang/vscode-go#1489
Change-Id: I235caf3960c7201af93800d65546fbab5c6e3f4b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/319129
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@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: Rebecca Stambler <rstambler@golang.org>
This CL adds various improvements for matching nested fields and
methods:
- Limit the symbols we produce to not show unqualified fields/methods,
and not show partial package paths.
- Handle embedded selectors, by trimming the package path.
- Improve the internal API used by symbolizers to operate on named
chunks.
Fixesgolang/go#46997
Change-Id: I86cbe998adbb8e52549c937e330896134c375ed7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334531
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>
I'm not sure how this can happen, but it seems possible that a bad
expression might somehow have an invalid position.
Fixesgolang/go#47231
Change-Id: I0794bdfb66f668fc375e9fe561c9f239c8b92492
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334892
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>
There is insufficient type information to compute semantic tokens in
packages that don't compile. Particularly affected are test files
and files being actively edited in new packages.
Further, existing code could
panic on poorly formed imports; this has been fixed.
Computing semantic tokens for identifiers
having neither use or definition information has been improved.
(Each of the many cases in the new function unkIdent() occurs
in existing code or test files.)
Change-Id: Id1b5db0622b17076de1ed23a950a20cd03c3750a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/333869
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: Robert Findley <rfindley@google.com>
If didModifyFiles fails we were never closing the diagnoseDone channel.
This was potentially leaking goroutines in the regtests.
Noticed in
https://storage.googleapis.com/go-build-log/ab4085ce/freebsd-amd64-12_2_149b05c3.log
Change-Id: I906b643d415c915d7be1951e5d8d21bf9016acee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334250
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 debounce API becomes both more testable and more elegant when using
channels rather than callbacks to signal events, as suggested by bcmills
in CL 333349. Adopt these suggestions.
Fixesgolang/go#45085
Change-Id: Ic1843f582d514af8aa109c24f5e3311536e54a60
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334252
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>
Jean-Hadrien Chabran
pjw
Chitoku
Rebecca Stambler
Robert Findley
Johannes Altmanninger
Muir Manders
Suzy Mueller
Shoshin Nikita
Nicholas Asimov
Pontus Leitzler
Karthik Nayak
danishprakash