Add some additional logging to help debug golang/go#53586
For golang/go#53586
Change-Id: I0574fb01be47b265cd6e412855794bc2cb836dff
Reviewed-on: https://go-review.googlesource.com/c/tools/+/414854
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
It turns out PointSpan was only ever used as part of an oft repeated
pattern to get a token.Pos from a protocol position. Cut out the
middle.
Change-Id: I0b2c0fc3d335e6bbd3c1ac72c6f75e2c40c60ca5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/408717
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
The TokenConverter has been trimmed down to a thin wrapper around
token.File, and can now be removed.
Change-Id: I9985492274c88e6a13e6d62dadab5595c75c7840
Reviewed-on: https://go-review.googlesource.com/c/tools/+/406134
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Eliminate the need to work around newline terminated files in
completion, by storing selection ranges as token.Pos and using an
lsppos.TokenMapper derived from the file content, which does not have
problems with newline termination.
This simplifies the completion logic, and removes the last use of
MappedRange.SpanRange, which is an inconisitent API in that it returns
positions in the compiled source, rather than edited source.
Change-Id: I65232787956325172b48fd42d85cbb598039ee5a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/407889
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
The existing debug.Bug mechanism for reporting internal bugs is
insufficient for several reasons:
- It requires a context, which is not always available.
- By being defined in the debug package, it is subject to import
cycles.
- It is too complicated. Listening for bugs requires understanding the
event package.
Replace this with a simpler 'bug' package with no dependencies, that
allows reporting, listing, and listening on internal bugs. Hopefully
this will fulfill the goal of debug.Bug, to help us track down rare
bugs.
Change-Id: I30cab58429b29bd2d944d62e94f5657e40a760fc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399623
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
This avoids an import cycle that prevented these wrappers from being
used in the lsppos package.
Change-Id: I9eedd256db983dfcf962edba39e3d4f3a1aabdeb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403680
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
While working on golang/go#52715, I discovered an infinite recursion in
gopls' completion logic: eachField assumes a finiteness of type pointers.
It is almost certainly a go/types bug that type-checked types expand
infinitely, but nevertheless we should use the more accurate
typeutil.Map for short-circuiting our search.
Change-Id: Ib1c7125e624f42882869acd4e0476e317d4da056
Reviewed-on: https://go-review.googlesource.com/c/tools/+/404335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Give placeholders for type params in func literal completions. For
example:
func foo[T any](func(T) T) {}
foo(<>)
Will now give "func(<T>) <T> {}" where <> denotes a placeholder.
Change-Id: Iadde73ed6b88e1410c28dfa33a20ab6a51235c93
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400616
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In cases like:
type foo[T any] struct{}
func bar[T any](foo[T]) {}
bar[int](<A>)
bar(<B>)
At <A> we will now offer "foo[int]{}". At <B> we will now offer a
snippet "foo[<T>]{}" which lets the user fill in the type arg.
Note that we have no knowledge of type inference, so you can be left
with superfluous type args after completion.
Change-Id: Ia7d63284f3317d9367864fdae3e3f9ae68fdff1a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400615
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In cases like:
func foo[T int | string](T) {}
foo[int](<>)
Previously at <> we would favor int and string candidates. This is
because go/types doesn't instantiate foo in this case (for some
reason). Work around the issue by using types.CheckExpr to re-check
the *ast.CallExpr.Fun. CheckExpr seems to do a better than a full type
check in the face of errors.
Updates golang/go#52291
Updates golang/go#52503
Change-Id: Ide436428f3232db2e06ea3cc22ea250edbf28685
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400614
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In cases like:
func foo[A int|string](a A) {}
foo[_](<>)
We now prefer ints and strings at <> by matching against the type
constraint. Note that even if "_" is replaced with "int", we still
prefer strings since the type checker doesn't seem to want to
instantiate foo unless the params check out.
Change-Id: I0e7acfef0775752a96fcfe23e7e2e3d939820eee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394017
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Auto-Submit: Peter Weinberger <pjw@google.com>
As of golang/go#50827, gopls no longer supports building at 1.12, and so
usage of golang.org/x/xerrors can be replaced with the native support for
error wrapping introduced in Go 1.13.
Remove this usage as a step toward eliminating the xerrors dependency
from x/tools.
For golang/go#52442
Change-Id: Ibf459cc72402a30a6c2735dc620f76ed8a5e2525
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401097
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Gofmt to update doc comments to the new formatting.
(There are so many files in x/tools I am breaking up the
gofmt'ing into multiple CLs.)
For golang/go#51082.
Change-Id: Ife11502fe1e59a04d53dba9edccd3043e57f9ae8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/399358
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I13cf73d7e043dda1a06c28bb09e413a76a68df1f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/391934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
For example:
func foo[A int | float64](a A) A { return a }
var _ int = fo<>
Previously at <> we would complete to "int(foo[A int|float64](a A))".
We added the int() type conversion because the returned type param A
was convertible to the expected "int" (i.e. both "int" and "float64"
can be converted). This is a premature suggestion, though, so fix by
suppressing such type conversions for type parameters.
Fixesgolang/go#51780.
Change-Id: I63e3bd401a4d9927b9261659812c521c02e33d94
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394016
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
In this example:
func foo[A []int | []float64]() {}
foo[<>]
When completing at <> you were getting the creative candidate
"[]int | []float64". This came from some code that makes the expected
type available as a candidate if it wouldn't otherwise be found by a
lexical search. I tweaked the code in this case to instead look at
each structural type in the type constraint rather than the constraint
as a whole. In the above example you now get the candidates "[]int"
and "[]float64".
Change-Id: Ib8e422df3009cb4253ec66005b4a53851564c4e1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394015
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Now when instantiating a generic function, we prefer type names that
are assignable to the corresponding constraint. For example:
func foo[A int|string]() {}
foo[<>]()
At <> we prefer the type names "int" and "string". Previously we had
no preference at all.
Updates golang/go#51782.
Change-Id: I7ed39ffa2bc4c63e9d320f47a58e139251712bb3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/394014
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
The argument to f.Fuzz is determined, up to the names of arguments,
by the types of the arguments to f.Add. Inside the function argument
of f.Fuzz, only f.Name and f.Failed are allowed.
(The fset passed to fuzz was for debugging. When the change seems solid
it can be removed.)
Fixesgolang/go#51089
Change-Id: Icf8b8cdfd29e499bcc605a358ca9edaef5baa835
Reviewed-on: https://go-review.googlesource.com/c/tools/+/387615
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL adds support for generating method stubs for named types
that have type parameters and want to implement an interface.
See internal/lsp/testdata/stub/stub_generic_receiver.go for an example.
Note, this CL does not yet support type params on interface declarations.
Updates golang/go#37537
Change-Id: I2a2a18d364b2b489e2fbd8a74dfed88ae32d83b5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/389654
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Suzy Mueller <suzmue@golang.org>
In test files, function definitions starting with
Test, Bench, or Fuzz can be completed almost automatically.
For the snippets the user hits tab, completes the name, hits
tab again, and the function is defined, except (of course) for its
body.
Otherwise a completion that fills in the signature is proposed.
Where appropriate, 'TestMain(m *testing.M)' is also offered as
a completion.
Fixesgolang/go#46896 and golang/go#51089
Change-Id: I46c05af0ead79c1d82ca40b2c605045e06e1a35d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385974
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Clean up the relationship between HoverContext and HoverJSON so that
HoverContext is more clearly responsible for collecting comment and
signature nodes, and HoverJSON is more clearly a DTO for the hover RPC.
Change-Id: Ib32d4151a53505d227b4225be4f87754a542e980
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385017
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The logic to resolve hover information is hard to follow, due to various
indirection building up the HoverInformation struct, and the lack of a
definition for HoverInformation.source. Incrementally refactoring to
solve these problems is a tricky; as a first step, split out that
information which is shared with completion and signature help into a
new type.
Also refactor FormatHover to be a bit more uniform.
Change-Id: Ib4f30e5f7cd085a3280c31836df3840ee3466b4d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385014
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change adds a list of conventional acronyms that are used for function
completion. For example, "err" for "error" and "tx" for "sql.Tx" or "sqlx.Tx".
Fixesgolang/go#48260
Change-Id: Iff951ee58c0c95389d474cc45dfd84b483ff71e3
GitHub-Last-Rev: 05ccd5a2fe95e2e0504d28230308c4888477a977
GitHub-Pull-Request: golang/tools#363
Reviewed-on: https://go-review.googlesource.com/c/tools/+/381969
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
CompletionItem.Label is what is shown to the user. Unless InsertText is
overridden by there being a TextEdit, InsertText should be the same
as Label.
Change-Id: I200739fbdfca19aa33154d5391b3ebcc79dd7af5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382243
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In
type SyncMap[K comparable, V any] struct {}
func (s *Syn
Syn sould be completed as SyncMap[K, V], as the type parameters
are required for receivers by the language definition.
fixesgolang/go#50684
Change-Id: I6946d41c49df8bbd336225718c36e3c17dde0b6f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380354
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Muir Manders <muir@mnd.rs>
Reviewed-by: Robert Findley <rfindley@google.com>
This adds two new snippets, centred around string manipulation.
The first snippet applies to variables of type string, and is called
split. When used, it replaces `someStringVar.split!` with
`strings.Split(someStringVar, "|")`, where `|` indicates the location of
the cursor.
The second snippet is essentially the same as the first, but in
"reverse". Meaning that rather than going from a string to a slice of
strings, it goes from a slice of strings to a single string:
`someStringSlice.join!` -> `strings.Join(someStringSlice, "|")`.
Change-Id: I0e303a39766463034687f76a5d9dbab419e2021b
GitHub-Last-Rev: 935cc418e75d54f0e5b1194cdb576c8829252a26
GitHub-Pull-Request: golang/tools#347
Reviewed-on: https://go-review.googlesource.com/c/tools/+/362474
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Guard against the panic in golang/go#49397, though it should not be
possible with well-formed AST.
Updates golang/go#49397
Change-Id: I3428504a4cfd361c1f51316d8c9aeee4aa9d7f42
Reviewed-on: https://go-review.googlesource.com/c/tools/+/364675
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This isn't strictly necessary for some of the cases, but it's better to
use it in all cases. Also added a test to ensure that we avoid
(*token.File).Offset in all of gopls--test was probably overkill, but it
was quick to write.
Change-Id: I6dd0126e2211796d5de4e7a389386d7aa81014f0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/353890
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Trust: 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 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>
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>
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>
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>
In cases like:
var foo func(...interface{})
var one int
var two func() (int, int)
foo(<>)
At <> we were preferring "two()" over "one" because we were really
excited that the multi return value function was usable. "one" was not
preferred because the expected value is interface{} (we default to
saying candidates _don't_ match interface{} to give non-type based
aspects of candidate inference a chance to shine).
Fix by applying the corresponding interface{} logic to the assignees
checking: ignore the case of completing into func(...interface{})
since all multi return value functions would match.
Fixesgolang/go#46378.
Change-Id: I355daa75e067e8b14508ca50b8d3b6b727df5fec
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323509
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
For example:
type foo struct { i int }
type bar struct { i int }
var _ foo = <>
Previously at <> we would offer "bar{}" in addition to "foo{}" because
we knew "bar" was convertible to "foo". The "bar{}" completion wasn't
valid as inserted, however, because we didn't include the type
conversion. Anyway, it doesn't make sense to include convertible types
since the directly matching type should also be available. Fix by
tweaking the literal candidate code to skip candidates requiring
conversion.
Fixesgolang/go#46113.
Change-Id: Ica5e4af7f2f8bb2f7e2361efe39694f8bb738c97
Reviewed-on: https://go-review.googlesource.com/c/tools/+/319509
Run-TryBot: Muir Manders <muir@mnd.rs>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
With the new ParseExported logic, we can lose some unexported fields on
exported structs. This can lead to misleading or malformatted hover
information.
Fix this by ensuring we always extract the Spec from a full parse. Since
this path is only hit via user-initiated requests (and should only be
hit ~once per request), it is preferable to do the parse on-demand
rather than parse via the cache and risk pinning the full AST for the
remaining duration of the session.
For golang/go#46158
Change-Id: Ib3eb61c3f75e16199eb492e3e129ba875bd8553e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/320550
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>
Despite the name, ParseExported only hollowed out declarations -- it
didn't actually drop any from the AST. This leaves a fair amount of
unexported crud behind. Unfortunately, there are a *lot* of ways to
expose an unexported declaration from an exported one, and it can be
done across files. Because of that, discarding unexported declarations
requires a lot of work.
This CL implements a decent attempt at pruning as much as possible from
the AST in ParseExported mode.
First, we analyze the AST of all the files in the package for exported
uses of unexported identifiers, iterating to a fixed point. Then, we
type check those ASTs. If there are missing identifiers (probably due to
a bug in the dependency analysis) we use those errors to re-parse. After
that we give up and fall back to the older, less effective trimming. The
pkg type changes slightly to accomodate the new control flow.
We have to analyze all the files at once because an unexported type
might be exposed in another file. Unfortunately, that means we can't
parse a single file at a time any more -- the result of parsing a file
depends on the result of parsing its siblings. To avoid cache
corruption, we have to do the parsing directly in type checking,
uncached.
This, in turn, required changes to the PosTo* functions. Previously,
they operated just on files, but a file name is no longer sufficient to
get a ParseExported AST. Change them to work on Packages instead. I
squeezed in a bit of refactoring while I was touching them.
Change-Id: I61249144ffa43ad645ed38d79e873e3998b0f38d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312471
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In cases like:
append([]string{}, foo<>)
we now prefer objects of type string at <>. Previously we had no
preference. In particular, we now try to infer the slice type from the
first append() arg instead of only from the outer context of the
append() call.
Fixesgolang/go#43240.
Change-Id: I59dfa3b18892c5c87fc5ff53109f51f50ee03d26
Reviewed-on: https://go-review.googlesource.com/c/tools/+/316849
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
ast.NewPackage mutates the input files, making it difficult to avoid
races with our caching model. I had avoided a race resulting from cache
handle cancellation, just to run into another race in multi-session
servers.
But there's no reason to use ast.NewPackage when we only have a single
file. We can just interrogate the file scope wherever needed.
Fixesgolang/go#45868
Change-Id: I521475b51ee3b1c3e408916affecafbc629b0191
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315629
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: Heschi Kreinick <heschi@google.com>
In LSP, CompletionItems can say if they are for deprecated names. This
CL implements that for items where the doc comments contain a line
starting // Deprecated.
Semantic tokens now similarly mark deprecated tokens, but in vscode
the default theme doesn't change the display, and the customization
options seem limited to:
"editor.semanticTokenColorCustomizations": {
"rules": {
// only foreground, bold, underline, italic
"*.deprecated": {"italic": true}
}
},
Change-Id: I93ccc227bf4e1e30a4f23b40da4d2cbafe1cd925
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313509
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>
Before this change directory names were used "as is" for package completion.
It could lead to invalid suggestions (for example, 'package 1abc' or package 'ab-cd').
This change adds a check whether a directory name can be used in a package path.
If the directory name is invalid, only 'package main' will be suggested.
Otherwise, the directory name will be normalized and will be used as a package name.
Note: normalized directory names contain only lower case letters and digits.
Fixesgolang/go#44680
Change-Id: I4b710f90d1723c512e29dc3c248a1e681f1cd37f
GitHub-Last-Rev: 8ae69f1c6fdf80831e5773bdb3507a8d51a4a0cf
GitHub-Pull-Request: golang/tools#310
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313092
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>
In cases like:
foo.<>
bar = 123
We weren't detecting that the selector preceding <> was a statement.
The above is parsed as "foo.<>bar = 123", so it looks like <> is
contained in an AssignStmt. This matters because we give different
postfix completions depending on whether it is valid to replace the
surrounding selector with a statement or not.
Updates golang/go#45718.
Change-Id: I8f74505b2c8c7060f1e94433904ff0a987d0cc57
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313269
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>
For example:
var b [4]byte
var s []byte = <>
At <> we now prefer "b" and insert as "b[:]".
Fixesgolang/go#40277.
Change-Id: I5fe9d153813dac7218edf31c7c33610130eef9bc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/311169
Run-TryBot: Muir Manders <muir@mnd.rs>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Don't offer deep completions when completing the name of unimported
packages.
For example:
var _ int = <>
Completing at <> previously would offer an eclectic array of
candidates such as "bits.LeadingZeros()", "time.Now().Day()", or
"zlib.BestCompression", depending on your luck. These candidates stem
from unimported packages candidates such as "bits" which we continue
searching into for deep candidates.
There are two main reasons these deep completions are not useful:
1. They are not dependable. Not all unimported packages are even
searched (it stops as soon as it finds a set number).
2. Fuzzy matching does not work (e.g. typing "bilz" will not filter to
"bits.LeadingZeros" as it does in other cases).
2) could be remedied, but there are so many unimported
package members that I'm not sure it is possible to reduce false
positive deep completions to a satisfactory level.
I also made a couple relevant minor tweaks:
- Fallback sort the unimported packages by path to keep a consistent
order.
- Don't offer unimported packages at all if there is no prefix.
Updates golang/go#43374.
Change-Id: I9fbcde34a3a9e7781568515bddab9da2fc931139
Reviewed-on: https://go-review.googlesource.com/c/tools/+/311069
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
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>
Robert Findley
Muir Manders
Russ Cox
Dan Kortschak
Peter Weinbergr
Marwan Sulaiman
Shoshin Nikita
A_D
Rebecca Stambler
Heschi Kreinick