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>
We should not offer links to variable or type declarations in function
scope. Improve our heuristics to check that the declaration object is
actually reachable from the package scope.
Also push down handling of private import paths, so that the
HoverJSON.importPath field can be removed.
Change-Id: I6edb3be3c37f479667c838beb49f97e7167b47a1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385016
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>
Hover on type specs was using the RHS of the type declaration and then
later rebuilding the declaration syntax. It was thereby dropping type
parameter lists.
Fix this by capturing the entire *TypeSpec for the signature, and
simply dropping comments from the node before formatting, so that they
are not duplicated.
Change-Id: I58724e65bd1f2aada1a5c04e4c61a059bed8357a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385015
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>
Thread through an adjusted object position when we format an re-parsed
AST that wasn't type-checked to produce the object. Also remove some
unnecessary handling of the object type.
Fixesgolang/go#46158
Change-Id: Ic8bee2bb4cb992d577d085599213fca1deab3b4e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/384697
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>
Receiver base types are either *Interface or *Named, never *Struct.
Absent a comment, I don't know why we had handling for *Struct, so just
delete it.
We only care about the enclosing type if it is named, so track a
*TypeName rather than an arbitrary Type.
Change-Id: I729c85b935a35da429b975327b56d81dc56773cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/384696
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 will make GOWORK value appear in the gopls log
when initializing the workspace. This CL does not include
GOWORK in `environmentVariables` (in view.go) (yet).
Change-Id: I16224d1ac50ac8209def008966371c6be858d05a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/385894
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This CL adds a quickfix CodeAction that detects "missing method"
compiler errors and suggests adding method stubs to the concrete
type that would implement the interface. There are many ways that
a user might indicate a concrete type is meant to be used as an interface.
This PR detects two types of those errors: variable declaration and function returns.
For variable declarations, things like the following should be detected:
1. var _ SomeInterface = SomeType{}
2. var _ = SomeInterface(SomeType{})
3. var _ SomeInterface = (*SomeType)(nil)
For function returns, the following example is the primary detection:
func newIface() SomeInterface {
return &SomeType{}
}
More detections can be added in the future of course.
Fixesgolang/go#37537
Change-Id: Ibb7784622184c9885eff2ccc786767682876b4d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274372
Reviewed-by: Heschi Kreinick <heschi@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>
This will validate that first letter after FuzzFoo() should be uppercase
Also, following validation will be performed for f.Fuzz() calls :
1. f.Fuzz() should call a function and it should be of type (*testing.F).Fuzz().
2. The called function in f.Fuzz(func(){}) should not return result.
3. First argument of func() should be of type *testing.T
4. Second argument onwards should be of type []byte, string, bool, byte,
rune, float32, float64, int, int8, int16, int32, int64, uint, uint8, uint16,
uint32, uint64
For golang/go#50198
Change-Id: I540daf635f0fe03d954b010b9b5f8616fd5df47a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/374495
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Peter Weinberger <pjw@google.com>
Wired through support for calling x/mod's go.work formatter on go.work
files into LSP. Tested it by hand in editor using the "Format Document"
command. Added a test case to workspace_test regtest, though I'm not
totally sure the test is correct.
For golang/go#50930
Change-Id: Ied052ded514bb36f561737698f0e2d7b488158e7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/383774
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When a prepare rename request is issued on an package
import with no alias, the range returned by prepare
rename has length 0. This by itself does not provide
enough information to the client about what the original
name of the import statement. By returning a range and
a placeholder, this allows the client to correctly present
the information about what is being renamed to the user.
Change-Id: I191fdc666616d1ddf718d2a0b1461b9b645af879
Reviewed-on: https://go-review.googlesource.com/c/tools/+/360836
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Reading the code and running the tests, it appears we only support quick
fixes for undeclared name errors inside function bodies. Don't offer
them in other places.
The specific situation raised was type constraints, so that's what I
tested even though the problem was much broader. Also add actual error
messages where we had empty strings.
Fixesgolang/go#50935.
Change-Id: I8dadcb6e4301bf22cbe7fe5d66064aafeef02690
Reviewed-on: https://go-review.googlesource.com/c/tools/+/384117
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change adds support for full documentation of builtin types in the
hover info, consisting of the type declaration, a link to pkg.go.dev,
and the text of the doc comments in the `builtin` pseudo-package.
Full documentation for builtin functions was already supported.
Removes the special case for the `error` interface, which is not needed
and didn't provide the full documentation anyway, only the type
declaration.
The code has to determine the parent ast.GenDecl (which holds the doc
comments) for the ast.TypeSpec of a builtin type.
Fixesgolang/go#50196
Change-Id: I51a054cd7e864300ba2e51152311744b7bcf3e0c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/383614
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>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
For some use-cases, it is helpful to compute predicates between
uninstantiated generic types.
This CL implements one such predicate for types.AssignableTo, a helper
GenericAssignableTo which reports if, for generic types V and T with the
same number of type parameters, all instantiations V[A_1, ..., A_N] are
assignable to the corresponding instantiation T[A_1, ..., A_N].
For #50887
For #50447
Change-Id: I7a0550fba05666bb2375d478d5390a123e09f556
Reviewed-on: https://go-review.googlesource.com/c/tools/+/383094
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Set the language version from the controlling go.mod file's go version,
if any. Also verify that we properly surface a diagnostic if the version
is invalid.
I didn't add any quick fixes.
Fixesgolang/go#50688.
Change-Id: Ic472502d1224a1decb5b989d51110b837020e998
Reviewed-on: https://go-review.googlesource.com/c/tools/+/383394
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add -json flag to output in JSON format.
Include the Go version info
- go1.18: runtime/debug.BuildInfo.GoVersion
- pre go1.18: runtime.Version
Restructure ServiceVersion so we embed info from
runtime/debug.BuildInfo. Instead of directly using
runtime/debug.BuildInfo, we use our own BuildInfo type.
That allows:
for go1.17 or older versions, we can add GoVersion.
for go1.18, we can drop MarshalText that prevents
JSON encoding other languages and human can understand
(golang/go#51026)
For golang/go#49783
Change-Id: Ia5ab50ce1f5e6c3a912654834785ecea7f5034e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382274
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The VS Code extension uses information about imports to figure out
whether a given function is a Testify test. As of writing, it asks:
- Does the file import Testify?
- Does the package it's in do so?
To answer these questions, add ListImports, which tells you about the
packages imported by the current file, including their import name,
plus the import paths of all imports in the entire package.
I suspect the latter may be wrong in the presence of GOPATH vendoring,
but that should be a relatively rare situation at this point so I didn't
bother testing.
Fixesgolang/go#40514.
Change-Id: I4c69e1db80dce6e594bdb595a81aade1ddec4d29
Reviewed-on: https://go-review.googlesource.com/c/tools/+/383354
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When using go 1.18 with go.work files, don't fake workspaces by creating
a workspace module: just run from the workspace root and pass -workfile.
For golang/go#44696
Change-Id: Iaa1979d26b1ce67c6e18e0bf26546a504069da8c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382241
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Remove the workspace_metadata command, as VS Code no longer needs this
to run workspace commands (it can use go.work instead).
Updates golang/go#44696
Change-Id: Ife579a15e64969c4301e4508e18b7c8a8b633b9f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382235
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: Gopher Robot <gobot@golang.org>
This CL fixes a several bugs in workspace invalidation:
- When invalidating the workspace due to a change in gopls.mod or
go.work files, we should not update the workspace if the change does
not parse. There was a comment to this effect, but it was not
properly implemented.
- Check go.work before gopls.mod, consistent with our intitial
workspace load.
- If we get an 'unchanged' change (such as a save) to go.work, don't
continue looking for gopls.mod.
A regression test that inadvertently relied on our mishandling of broken
go.work files is updated to have the correct syntax. A new regtest
expectation is added to assert on a clean workspace.
For golang/go#44696
Change-Id: I2b7e739573e225cadfbf8cc892a0b5daf0191e40
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382115
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Remove some duplication in the construction of cache.workspace
instances.
For golang/go#44696
Change-Id: Ic955fa3f9a574781f627c550694f0b87ad2013e1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382114
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Gopls was using an old version of workfile support in x/mod that did not
support the 'use' syntax.
Upgrade to x/mod@master, and update tests accordingly.
For golang/go#44696
Change-Id: I87841cd1322d7b1aa0fbc929838746ea600bee77
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382078
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
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>
For dense queries, the fastfuzzy matcher is around 3x faster. It also
has improved scoring for exact matches of CamelCase words or path
segments.
Fixesgolang/go#50016
Change-Id: I04cae11cbc54de59d54733836876a9ee759c80b6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382394
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
With instantiated types, method objects are no longer unique: they may
be instantiations of methods with generic receiver. However, some
use-cases require finding the canonical method representing the method
in the source. For these use-cases, provide an OriginMethod helper.
For golang/go#50447
Change-Id: I6f8af3fb5c5eeefb11f8f3bdba54cd6692ca389f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380554
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tim King <taking@google.com>
The 'go' command reads the main module's 'go.mod' file with the file
locked. If 'gopls' starts a 'go' command in the background that reads
the 'go.mod' file, there is a narrow window in which that read can
race with the test's ioutil.WriteFile.
This change retries the write (as a user would probably do), fixing
the test failure. However, I suspect that there may be a broader UX
issue here that it will mask: in order to actually avoid the race
without a locking error, something in the LSP protocol needs to be
synchronizing gopls-initiated reads with editor-initiated writes. The
test failure this fixes indicates that that synchronization seems not
to be happening.
Fixesgolang/go#50971
Change-Id: Iba140277bf957bae4937cc23f62d3aac817a7d36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382414
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This no longer has an invalid usage line, and mentions the help command.
It also mentions the no command form that is the same as serve.
For #41860
Change-Id: I9add50d295e1eb66152876617f27761a9441e67f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/367842
Trust: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also modify the printing so that it groups flags that work on the same
value into the same flag usage line.
For #41860
Change-Id: I97fdd3e64f24b22c15780b636789f512eb46ed2c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/367838
Trust: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Ian Cottrell <iancottrell@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add a copy of flag.PrintDefaults so that we can make changes.
This CL does not actually modify anything (although it does have
to detect the private stringValue type a slightly different way)
For #41860
Change-Id: I19512041f9c1bfde56226aea48302cd63cf670e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/367837
Trust: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This makes lots of changes to make the help text more self
consistent, and fix up some broken things.
For #41860
Change-Id: I79f7f6ab12a3a833d15f53b3cd71208dfa1d6e10
Reviewed-on: https://go-review.googlesource.com/c/tools/+/367835
Trust: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This adds a small script and uses it to write all the help text
to files.
This will be used to show the diff of a collection of changes to
come.
For #41860
Change-Id: Iaef52365d421dd3c375d22ac5a1f7c5eb6b69ac2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/367834
Trust: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.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>
We care that gopls operations complete within a reasonable time.
However, what is “reasonable” depends strongly on the specifics of the
user and the hardware they are running on: a timeout that would be
perfectly reasonable on a high-powered user workstation with little
other load may be far too short on an overloaded and/or underpowered
CI builder.
This change adjusts the regtest runner to use the test deadline
instead of an arbitrary, flag-defined timeout; we expect the user or
system running the test to scale the test timeout appropriately to the
specific platform and system load.
When the testing package gains support for per-test timeouts
(golang/go#48157), this approach will automatically apply those
timeouts too.
If we decide that we also want to test specific performance and/or
latency targets, we can set up specific configurations for that (as
either aggressive per-test timeouts or benchmarks) in a followup
change.
For golang/go#50582
Change-Id: I1ab11b2049effb097aa620046fe11609269f91c4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380497
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We may want to generalize this to have regtest.Run always derive the
default timeout from the test's deadline. In the meantime, this is a
more targeted fix for the specific timeout in TestGCDetails.
Fixesgolang/go#49902
(Maybe.)
Change-Id: Ie15735dc7b0d462ec047d3f3d8a2eceeb4411fa0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380496
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL begins adding a guide for the new APIs introduced with Go 1.18
to support writing tools that understand generic Go code.
For now I've added a summary of the new APIs, an initial example, and
some discussion of the typeparams package. Subsequent CLs will add more
examples, and polish.
Updates golang/go#50447
Change-Id: I4ed8d7a2f43e748374d14f3f515673d69ab2d5a0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/377834
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Dominik Honnef <dominik@honnef.co>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
snapshot.GetVersionedFile already memoizes the file handle in
snapshot.files. There is no reason to do another write, and this write
is unsynchronized.
Fixesgolang/go#50747
Change-Id: Ib196395135de6f22dd59169accb756665ad10e58
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380214
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change makes source.FormatVarType return the instantiated type
parameter instead of the actual AST expression because that will just
refer to the abstract type parameter and not the insantiated one.
I am not sure if this covers all edge cases or if there's a better
solution but I'm happy to adjust to whatever is appropriate.
Fixesgolang/go#50623
Change-Id: I6e0b2d93c47c9a0502f2995ca8d3668a9a31c056
Reviewed-on: https://go-review.googlesource.com/c/tools/+/378714
Trust: Robert Findley <rfindley@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: Peter Weinberger <pjw@google.com>
Update and expand on the package documentation for the
internal/typeparams package.
Change-Id: I2af16250580abf9e6b3a8692356faa498ba83f29
Reviewed-on: https://go-review.googlesource.com/c/tools/+/377654
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The IndexExprData type of internal/typeparams was redundant now
that the typeparams.IndexListExpr type has been introduced. Remove it,
and change GetIndexExprData to an UnpackIndexExpr method, symmetric with
PackIndexExpr. With the IndexListExpr type, both UnpackIndexExpr and
PackIndexExpr can be moved to common.go.
Change-Id: I6c31f52ab594175decfbd1a4cd94b60a23a1e629
Reviewed-on: https://go-review.googlesource.com/c/tools/+/377235
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We have inconsistent rendering of newlines in enums, as pointed out in
CL 314189 (that change edited the markdown directly, which won't work).
Change-Id: Ie39b80fe65287bd447d18cacdaea60b24b4bd08f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/369957
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The fastfuzzy matcher is around 3x faster than the fuzzy matcher for
queries that need to search a large number of symbols, and has improved
scoring due to built-in knowledge about the structure of Go symbols.
Enable it in experimental builds of gopls, with plans to enable it by
default in the next release.
For golang/go#50016
Change-Id: Ie2c333f248bb8397d92f52fbbfdd2bf623372d0a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/377434
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: Gopher Robot <gobot@golang.org>
I'm not sure how to hit this in practice, since it appears that symbols
should only return errors with some type of corruption, but we should
keep going when searching for symbols in snapshot files.
Change-Id: I9fcf6cc92fdc943520e8890ece51d28ec46e8812
Reviewed-on: https://go-review.googlesource.com/c/tools/+/376363
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Findley
Hana
Marwan Sulaiman
Nooras Saba
Michael Matloob
Suzy Mueller
Heschi Kreinick
fzipp
Shoshin Nikita
pjw
Bryan C. Mills
Ian Cottrell