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>
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>
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>
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>
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>
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>
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>
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>
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>
When we open a file in a package, independent of whether it is in the
workspace, we type check in ParseFull mode. However, several other
code paths don't find this better parse mode.
We need a better abstraction, but for now improve a couple code paths
specifically for the purpose of fixing Hover content.
Updates golang/go#46158
Updates golang/go#46902
Change-Id: I34c0432fdba406d569ea963ab4366336068767a2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/333689
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>
*ast.AssignStmt doesn't have an associated comment group. So, we should
try to find and return a comment just before the identifier.
Fixesgolang/go#42134
Change-Id: Ie40717a4973ccfdbd99c3df891c2cfffbb21742d
GitHub-Last-Rev: da75fde2dbf3613f3325dbc5930dfc84ea813b90
GitHub-Pull-Request: golang/tools#323
Reviewed-on: https://go-review.googlesource.com/c/tools/+/327229
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>
This option has been enabled by default for a while now: remove it from
'experimental' to 'advanced'.
Change-Id: Id8116bf7b8976204a61fe1bbf9dc0b8bd69c68d1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309271
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>
Gopls's serial processing of didChangeWatchedFile notifications has
historically been a pain point for clients that don't batch file events,
when branch switching or running go generate.
It's "not that tricky" for us to debounce and batch up watched file
notifications on our end, so this CL introduces this functionality as a
new experimental setting. Truth be told it ended up being harder than
expected, due to (1) our requirement for regtests to be able to
determine when diagnostics have completed, and (2) our reliance on
jsonrpc2 for sequencing changes to the server.
To address (1), I factored out the actual processing of change
notifications into a separate method (thus increasing our surprisingly
long chain of method calls). To address (2), I guarded the processing of
file changes with a mutex.
I also guarded some places where views and snapshots were accessed in
potentially racy ways. Our interaction with session.views was rather
complicated, so I had to switch session.viewsMu to a RWMutex.
Add this to the experimental regtest mode, and more generally enable all
experimental features in this mode, rather than just the experimental
workspace module.
Fixesgolang/go#41691
Change-Id: Ifccdbdf86263dbe2e37ffe9f7bbf2a2cd74218b4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309269
Trust: Robert Findley <rfindley@google.com>
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: Heschi Kreinick <heschi@google.com>
As an experiment, this CL introduces the first gopls feature that is
specific to generics: enriching function hover information with inferred
types. This is done with no additional gating on build constraints by
using the new internal/typeparams package.
The marker tests are updated to allow tests that rely on type parameters
being enabled.
Change-Id: Ic627d64b61a6211389196814edd0abe1484491eb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317452
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>
Sometimes, we may want to report progress from functions inside of the
cache package, so move the progress tracker to the session to allow for
that.
Change-Id: I15409577a7a5080e7f0224a95d159de42856ffa7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/319330
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>
Retrying CL 271477, this time with parts of CL 322650 incorporated.
This CL moves to a model where we don't automatically delete invalidated
metadata, but rather preserve it and mark it invalid. This way, we can
continue to use invalid metadata for all features even if there is an
issue with the user's workspace.
To keep track of the metadata's validity, we add an invalid flag to
track the status of the metadata. We still reload at the same rate--the
next CL changes the way we reload data.
We also add a configuration to opt-in (currently, this is off by
default).
In some cases, like switches between GOPATH and module modes, and when a
file is deleted, the metadata *must* be deleted outright.
Also, handle an empty GOMODCACHE in the directory filters (from a
previous CL).
Updates golang/go#42266
Change-Id: Idc778dc92cfcf1e4d14116c79754bcca0229e63d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324394
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>
This change treats the GOMODCACHE like a directory filter, and it
excludes any modules under the module cache from being considered part
of the workspace. This can happen when users open their entire GOPATH.
To do this, I had to propagate the view's root and gomodcache through
the exclusion functions, and I also had to add BuildGoplsMod to the
snapshot's interface.
Change-Id: Id80b359d73d09a525b380389917451e85357b784
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326816
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>
This CL cleans up doc/commands.md to include missing command
documentation and add support for result parameters.
Included are some quick-and-dirty extensions to the command metadata
loader that handle slices and arrays of struct types.
Change-Id: I43a85e88c9c53e21b790d89a45a9de444addcc63
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326909
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 array, slice, maps and chan candidates, we now support
transforming them to their element type in completions. For example:
var m map[string]int
var _ int = m<>
At <> we complete to "m[]" because we see that the map value type
matches our expected type.
Fixesgolang/go#46045.
Change-Id: Ibee088550193a53744f93217cc365f67f301ae90
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323451
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Now we search up to three levels for candidate modifiers. For example,
we can now complete "foo" to "foo()()" (double invocation).
Granted this is rarely useful, but it generalizes and simplifies the
searching we did for dereference modifiers.
Updates golang/go#46045.
Change-Id: Ibf0be8158e16a0a26a6344a346f34af8fe182bb0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323450
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
"type mod" refers to agglutinative expressions such as dereference
"*", invocation "()", and slicing "[:]". When considering an object as
a completion candidate, we check whether applying a type mod would
make it a better candidate.
Previously we tracked the type mods we wanted to apply to a candidate
by setting bool fields. Now instead we keep a slice of the type mods.
This has two main advantages:
- The mods are now ordered which will allow us to format candidates
properly when the same mods can appear in different order (e.g.
"<-*foo" or *<-foo").
- We can now record any mod multiple times allowing for "<-<-foo" or
"foo()()".
I changed the formatting code to always create a snippet object since
that made things simpler. I had to tweak a few snippet helper methods
to accept a snippet argument rather than creating a new snippet.
This commit's only functional change is that we no longer show any
type mods in candidate labels. For example, the user will now see
"foo" in the completion popup instead of "*foo". Showing the operators
adds noise to the candidate list, and we didn't display them
consistently.
Updates golang/go#46045.
Change-Id: I3ea7baa1ee2fee80a1f8cfe88cbae1093ae269ba
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323449
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
If new functions or variables need to be created during an extract
call, then we choose the new names. This change makes those names
more descriptive to make the generated names easier to read and
understand.
Before:
cond0, ret0 := fn0()
if cond0 {
return ret0
}
After
shouldReturn, returnValue := newFunction()
if shouldReturn {
return returnValue
}
Change-Id: I44795dc45185c75d5bf65e48378aa54d6c156212
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326112
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>
When choosing variable names, extract makes sure that the chosen
name does not conflict with any existing variables. By avoiding these
conflicts, we may actually have a conflict with the other names we
are choosing. This change removes this conflict by sending the next
index to use as the suffix of the function name.
Change-Id: Icd81b67db29db2503e214d24ec19ca1065cda090
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326111
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Block comments are a single comment that stretches across multiple
lines. The folding range code made assumptions that each comment
was a single line. This change fixes the folding range logic to check for multiline comments and adjust the folding range to start at
the end of the first line.
Fixesgolang/go#46253Fixesgolang/vscode-go#1511
Change-Id: I902f6cda7547cb1f8b4cd447152c3cf29a691d3b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/325071
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>
This reverts commit 46e69bf3b2.
Reason for revert: Still has bugs associated with it and want to do a release
Change-Id: Ifa80bde147aa23aa4029a157d5dbaf6479d53024
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324290
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>