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>
These include call and return statements as well as closure creations
and panics/recovers.
Change-Id: Iee4a4e48e1b9c304959fbce4f3eb43eecd8cb851
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323049
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>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Collections include channels, slices, ranges, maps, and their related
SSA statements.
Statements involving functions and function calls will be addressed in a
future CL.
Change-Id: I552cbf3ee9d65e125270db69d1fc3c3f6491b121
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322951
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>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The getgo tool was using the golang.org version as the latest
version to fetch. But this is not always the latest version.
We now use https://golang.org/dl/?mode=json which is the
official latest version.
Fixesgolang/go#42676
Change-Id: I1cd90bfba12b19759599e89b7b4a095700999c09
Reviewed-on: https://go-review.googlesource.com/c/tools/+/270878
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
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>
A lot of the time spent for every file change is recomputing the set of
known subdirectories in the workspace. We can easily memoize these known
subdirectories and avoid recomputing them on every file change. Do that
here and update the set as file creations and deletions come in.
Updates golang/go#45686Fixesgolang/go#45974
Change-Id: Ide07f7c90f0cafc3a3cc7b89ba14ab82d4e3ab28
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317410
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>
Basic SSA program statements include storing and loading from a
register, storing and loading from a field, unary operations, make
instructions, tuple extractions, and type conversion/assertions.
Support for collections, including channels, and function calls will
happen in future CLs.
Change-Id: I2ab988dbdc5cfe67ba7f3946910a03416045ec6c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322950
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>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The test doesn't necessarily need to require exactly 2 log messages, so
the match doesn't need to be so exact.
Updates golang/go#46546
Change-Id: I6ec5dee820c76c41db7b1d4bad3925fc7afe25e4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324760
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
As part of debugging CL 324394, I found that we were returning
intermediate test variant packages in packageHandlesForFile. This
happened because, even though these packages were not workspace
packages, they would still be picked up by the file URIs -> IDs map.
This is typically not a problem when we are picking out the widest or
narrowest package for a specific request, but for diagnostics on changed
files, we run them on all of the possible packages. This also led to us
analyzing these intermediate test variant packages. Filter them out, as
we will never want them for this purpose.
Change-Id: Ifa780cd104f9c4b3fe6c530402956e2337c8fcdc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324689
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 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>
Also make Export create all parent directories before all files.
If the files are symlinks to directories, the target directory must
exist before the symlink is created on Windows. Otherwise, the symlink
will be created with the wrong type (and thus broken).
Fixesgolang/go#46503
Updates golang/go#38772
Updates golang/go#39183
Change-Id: I17864ed66e0464e0ed1f56c55751b384b8c59484
Reviewed-on: https://go-review.googlesource.com/c/tools/+/234112
Trust: Bryan C. Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This reverts commit 5ab822f631.
Reason for revert: Too early to enable since we need to figure out a plan for formatting directives
Change-Id: I46567b271d4ecd7e4af574221520a72bd8b8e500
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324289
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently we don't consider function literals in outgoing call
hierarchy, because we only consider expressions of type
`ast.SelectorExpr` and `ast.Ident`. So function literals are skipped.
Fix this by ensuring we traverse through other types even if we
don't add the type itself as an outgoing call hierarchy.
Fixesgolang/go#43438
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Change-Id: I9eacbd5ec7a68224518bf0e405319adeb673c853
GitHub-Last-Rev: 3e7118a8fd090b339a3eacf32fa8d62e05a76b87
GitHub-Pull-Request: golang/tools#320
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323809
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
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>
The specific package we run on doesn't matter, but using unsafe will
be a lot faster than running on whatever package the working directory
is pointing at.
Change-Id: Iae65a262c9bb129f8c8442a72cebf131521357ee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323390
Trust: Dominik Honnef <dominik@honnef.co>
Run-TryBot: Dominik Honnef <dominik@honnef.co>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This test is flaky due to orphaned file reloading. Since it is for an
experimental feature, skip it until we understand the problem.
For golang/go#46375
Updates golang/go#46183
Change-Id: Id6b369f2b61730c8503e3532547708f7689343c3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322649
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This is the first CL for the Variable Type Analysis (VTA) callgraph. It
provides the definition for VTA nodes and graph used to infer how types
flow through the Go program. This CL is first in the series of CLs that
build VTA type propagation graph.
The VTA algorithm is described in the paper called ``Practical Virtual Method Call Resolution for Java."
Change-Id: I2e4eafa139c6fdfba4bd709f041762ddc6174188
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313749
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Tim King <taking@google.com>
Trust: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Staticcheck's new quickfix category contains optional code
refactorings, such as turning a chain of if/else-if into a switch
statement, or simplifying boolean expressions.
These checks produce diagnostics with the "hint" or "information"
severities. Most use "hint", which produces a subtle hint in VSCode's
UI that a refactoring is available. "information" produces a blue
underline and is only used for those checks that have a very high
likelyhood of improving code readability.
Change-Id: I8f5b4eca67eb6b4e45c17510459d83eb673384e3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322492
Trust: Dominik Honnef <dominik@honnef.co>
Run-TryBot: Dominik Honnef <dominik@honnef.co>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Each analyzer in Staticcheck is annotated with the appropriate
severity to use for its diagnostics. For example, most checks in SA*
produce warnings, but some produce errors (e.g. when passing an
invalid regular expression to regexp.Compile).
This will be especially important for a follow-up CL that enables
Staticcheck's new quickfix category, which contains optional
refactorings that shouldn't be flagged as warnings.
Change-Id: I6235303a3bb188ef79f52952c01e9585301a3270
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322491
Trust: Dominik Honnef <dominik@honnef.co>
Run-TryBot: Dominik Honnef <dominik@honnef.co>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
CL 303230 renamed the linux-arm builder to linux-arm-scaleway, but the
x/tools ExitIfSmallMachine guard was not updated accordingly, resulting
in consistent failures for some tests.
For golang/go#45931
For golang/go#46183
Updates golang/go#32834
Change-Id: Ief5f17fc61cb38cf6b7cf63b6cd5e64f9d56261e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322409
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>
There was a lot of duplicated code throughout the gcimporter test.
Change-Id: Ib232717783b2b4053fa41139dfad05f37662072a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322290
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: 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 two codelenses that are attached to the module statement are
'Run go mod tidy' and 'Create vendor directory'. In a 'go.mod' file
without any required modules, the only codelens that shows up is
the 'Create vendor directory'. With no required modules, there is nothing
to vendor, but 'Run go mod tidy' may actually clean up the go.mod and go.sum,
so this is the codelens we want to appear.
Change-Id: I7264f8c4c4427a66264684f71fd4407b2170609f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322292
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>
There are no changes that affect gopls. The changes are for forthcoming
3.17 features.
Change-Id: Ic18872a9de980ce777b6d5384166de6ee9944622
Reviewed-on: https://go-review.googlesource.com/c/tools/+/322249
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@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>
This CL adds two new commands that let a client request a list of importable packages relative to a Go file and then select which import a programmer would like to add to said file.
Updates golang/go#43351
Change-Id: If12518874a92ed4167bdd711a92e03ee21c7b949
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281412
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>
- Use func.FullName() everywhere we can, since simply Printf or Errorf is often ambiguous.
- Give more specific error output when unsupported %w directive is used.
Change-Id: Ic2b423d87f9bedde459c79ce5aae622e9a4b5266
Reviewed-on: https://go-review.googlesource.com/c/tools/+/301949
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The old code mistakenly presumed all clients would want the standard
set of semantic tokens in the LSP specification, but clients have the
option of asking for fewer, so gopls should only use those.
Change-Id: Ic396bf3a2ba1fc3c9b48a380265a6cfded0a8bf6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/321470
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
computing the length by hand avoids an allocation.
Change-Id: Idc15f9347628b3b68cb3722d03c2c706a4f60a68
Reviewed-on: https://go-review.googlesource.com/c/tools/+/321469
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
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.
Updates golang/go#42266
Change-Id: Iff5e10b641fdb4be270af0cd887a10ee97ac1a19
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271477
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This change simplifies the code and fixes the issue with
extra new lines. It also adds unit tests.
Fixesgolang/go#43257
Change-Id: If4f6d939b2b0521e7bcce930838d539a6f0f9004
GitHub-Last-Rev: b5dd778524dbf55c1cf83af8175cdb6e8f4959ae
GitHub-Pull-Request: golang/tools#300
Reviewed-on: https://go-review.googlesource.com/c/tools/+/307709
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The semantic token legend sent to the client in registerCapability
wasn't the one used when encoding semantic tokens.
If a client sent clientCapabilities support for token types and token
modifiers that wasn't ordered exactly as gopls defined them, all
semantic tokens was encoded incorrectly.
We now instead report the order used for encoding as legend in the
registerCapability request to the client.
Fixesgolang/go#46244
Change-Id: I8273c9ed9d1f97a93c162d709f30df38bfd576aa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/321029
Trust: Pontus Leitzler <leitzler@gmail.com>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Use the jsonrpc2_v2 Preemption option to support request cancellation.
Also fix the TestRequestCancellation to actually test request
cancellation, and add a V2 version of this test. For now, the
ForwardBinder is not exercised.
Factor out test set-up and tear down.
Change-Id: Ic104e922fa2d0ae570b69c3928e371175db28a9f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/321014
Trust: Robert Findley <rfindley@google.com>
Trust: Ian Cottrell <iancottrell@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: Ian Cottrell <iancottrell@google.com>
Update the protocol package to allow wrapping the jsonrpc2 API, and add
wrappers for v1 and v2 of the API, so that we may switch between them.
Add simple bindings for the lsprpc package for jsonrpc2_v2 package, and
get them working well enough to pass a version TestClientLogging test.
This seemed like a reasonable checkpoint.
Also add some type safety to client closing: all LSP clients must
implement io.Closer.
Change-Id: Ib2e6906e0db0c94102a7e794de932d6b61d54670
Reviewed-on: https://go-review.googlesource.com/c/tools/+/320850
Trust: Robert Findley <rfindley@google.com>
Trust: Ian Cottrell <iancottrell@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: Ian Cottrell <iancottrell@google.com>
There was already handling in isClosingErr for errors from Stdin/Stdout
and TCP connections. Add handling for io.Pipe closing errors.
Change-Id: I8d171ab49a3fffe0fca9f0482f6b92d61b1fae1f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/320849
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: Ian Cottrell <iancottrell@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>