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>
Currently, testinggoroutine only inspects functions literal invoked as
"go func(){ ... }()".
For defined or anonymous functions like "go f(t)" it didn't traverse the
function body. To fix this, on encountering those kinds of functions,
retrieve the definition node then inspect it.
Fixesgolang/go#47470
Change-Id: I83b6eb3bf2689c66aee32f13d34002aa3cd175b2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338529
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
If we know that a nil slice is converted to a non-zero length array
pointer, warn user that this operation will always panic.
Updates golang/go#47326
Change-Id: Ic8adcc0255ddc621c5626dc5c525899b13e1c6b3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/337709
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tim King <taking@google.com>
Updates golang/go#47326
Change-Id: I6b9b59e82b1b93f7a328ba802ad473d4104d7577
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339890
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Guodong Li <guodongli@google.com>
Trust: 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>
I fixed a check in sandbox.go to check for size of config.Files
instead of nilness. The completion benchmarks run with an absolute
path workdir and were failing this check due to a non-nil but empty
config.Files.
I tweaked the benchmark output so it is compatible with benchstat. In
particular, the benchmark output now appears all on one line for an
imaginary benchmark named BenchmarkStatistics.
I also made a couple changes to the completion benchmarks:
- Don't modify the buffer before every completion. Type checking
completely dominates completion, so if it has to type check every
time then you aren't benchmarking the completion code at all.
- Don't try to exclude GC from the benchmark. I think amortized GC
time should be included in the benchmark timing. Plus, I'm not sure
that forcing a GC every 10 iterations was actually doing a good job
excluding GC from the benchmark.
Change-Id: I53718a5f6e25453146ccf5bb5fdfdfc65e244df3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323251
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Cherry Mui <cherryyz@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: Robert Findley <rfindley@google.com>
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>
With register ABI, for an ABIInternal function, understand that
the result may be written to a register instead of to memory.
TODO: argument area size calculation is still not fixed for
register ABI.
Change-Id: I109a5dc03ff0acc4bc04502710daf32efd1b08f6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/339250
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
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>
No interesting type flows so the change to vta itself is to not reject the instruction.
Updates golang/go#47326
Change-Id: Ifd11a7ef854afaee3978796f3113ca3254301d19
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338849
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Trust: Roland Shoemaker <roland@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>
Correct a typo in the objectpath documentation.
Change-Id: I85958d2529c6254466103738827ce3899d476b0b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334309
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@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>
Converting from nil slice to a zero length array pointer must be nil.
Updates golang/go#46987
Change-Id: I8894b92bd85fae8ea77bf01b92ee56f1a215a75b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/336489
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The existing implementation has an error coordinating the types of the
expressions 'k, v' in a range statement over a map 'k, v := range m'.
In particular, 'k', 'v' may have types other than the key and value
types of m and the difference between these types affects the constraint
generation of *ssa.Next (used to model iterating over maps). This fix
simply calculates the offset of the destination (the *types.Tuple of
*ssa.Next) independently from the offset of the source (the map 'm' in
the example above).
Fixesgolang/go#45735
Change-Id: Ib11846a94c23f8815fa502bdb7f80ef0803bf182
Reviewed-on: https://go-review.googlesource.com/c/tools/+/335889
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@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>
Adds a new tool, file2fuzz, which allows converting existing files into
the corpus format used by the Go fuzzer.
Change-Id: Ic0cd4bc3e8aa6d47489a460ea170a3f38b7b45e9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/336049
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In case the file separator line does not define a filename, it should be
ignored.
Updates golang/go#47193
Change-Id: I3a0fee584c0f6b2b41814e79d20884d6468a3b76
Reviewed-on: https://go-review.googlesource.com/c/tools/+/336932
Run-TryBot: Jay Conrod <jayconrod@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@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>
Going from an import line to an import block with CRLF endings did not
previously work.
Fixesgolang/go#47200
Change-Id: I51334587ad51b828bd0828217ba39fb745d7e835
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334890
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>
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>
CL 332049 added support for slice to array pointer, which introduced in
go1.17, by using Convert instruction. However, the conversion can fail
dynamically, while all current conversion instructions can not. That
leads to inconsistent with other parts of SSA IR.
@timothy-king suggested to add new instruction for this conversion, this
CL implements that.
Fixesgolang/go#46987
Change-Id: I1a00d51e257d2b3eabc2c37e3a09b78754193a78
Reviewed-on: https://go-review.googlesource.com/c/tools/+/333749
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tim King <taking@google.com>
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>
The documented Lua function for supporting imports with Neovim native
LSP support does work for imports, but also runs any other code action
available in the current range. For example, if the function was to run
with the user's cursor on an empty struct being initialized, the code
action for filling that struct would also run.
This change restricts the desired actions to only be organizeImports.
Fixesgolang/go#47181
Change-Id: Ie4eb5961cb4405091477b79175acc7052ff16d4c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/334749
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Robert Findley <rfindley@google.com>
Rebecca Stambler
Cuong Manh Le
Cuong Manh Le
Tim King
Robert Findley
Muir Manders
Suzy Mueller
pjw
Cherry Mui
Shoshin Nikita
Nicholas Asimov
Adin Scannell
Pontus Leitzler
Scott Cotton
Roland Shoemaker
Paschalis Tsilias
Karthik Nayak
danishprakash
Francesco Renzi