For array, slice, maps and chan candidates, we now support
transforming them to their element type in completions. For example:
var m map[string]int
var _ int = m<>
At <> we complete to "m[]" because we see that the map value type
matches our expected type.
Fixesgolang/go#46045.
Change-Id: Ibee088550193a53744f93217cc365f67f301ae90
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323451
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Now we search up to three levels for candidate modifiers. For example,
we can now complete "foo" to "foo()()" (double invocation).
Granted this is rarely useful, but it generalizes and simplifies the
searching we did for dereference modifiers.
Updates golang/go#46045.
Change-Id: Ibf0be8158e16a0a26a6344a346f34af8fe182bb0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323450
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
"type mod" refers to agglutinative expressions such as dereference
"*", invocation "()", and slicing "[:]". When considering an object as
a completion candidate, we check whether applying a type mod would
make it a better candidate.
Previously we tracked the type mods we wanted to apply to a candidate
by setting bool fields. Now instead we keep a slice of the type mods.
This has two main advantages:
- The mods are now ordered which will allow us to format candidates
properly when the same mods can appear in different order (e.g.
"<-*foo" or *<-foo").
- We can now record any mod multiple times allowing for "<-<-foo" or
"foo()()".
I changed the formatting code to always create a snippet object since
that made things simpler. I had to tweak a few snippet helper methods
to accept a snippet argument rather than creating a new snippet.
This commit's only functional change is that we no longer show any
type mods in candidate labels. For example, the user will now see
"foo" in the completion popup instead of "*foo". Showing the operators
adds noise to the candidate list, and we didn't display them
consistently.
Updates golang/go#46045.
Change-Id: I3ea7baa1ee2fee80a1f8cfe88cbae1093ae269ba
Reviewed-on: https://go-review.googlesource.com/c/tools/+/323449
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
If new functions or variables need to be created during an extract
call, then we choose the new names. This change makes those names
more descriptive to make the generated names easier to read and
understand.
Before:
cond0, ret0 := fn0()
if cond0 {
return ret0
}
After
shouldReturn, returnValue := newFunction()
if shouldReturn {
return returnValue
}
Change-Id: I44795dc45185c75d5bf65e48378aa54d6c156212
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326112
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When choosing variable names, extract makes sure that the chosen
name does not conflict with any existing variables. By avoiding these
conflicts, we may actually have a conflict with the other names we
are choosing. This change removes this conflict by sending the next
index to use as the suffix of the function name.
Change-Id: Icd81b67db29db2503e214d24ec19ca1065cda090
Reviewed-on: https://go-review.googlesource.com/c/tools/+/326111
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Block comments are a single comment that stretches across multiple
lines. The folding range code made assumptions that each comment
was a single line. This change fixes the folding range logic to check for multiline comments and adjust the folding range to start at
the end of the first line.
Fixesgolang/go#46253Fixesgolang/vscode-go#1511
Change-Id: I902f6cda7547cb1f8b4cd447152c3cf29a691d3b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/325071
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Suzy Mueller <suzmue@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This reverts commit 46e69bf3b2.
Reason for revert: Still has bugs associated with it and want to do a release
Change-Id: Ifa80bde147aa23aa4029a157d5dbaf6479d53024
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324290
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
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>
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>
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>
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>
Support typeDefinition for functions/methods that have only one return value
of a named type. The total number of return values doesn't matter.
Examples:
* func foo() X
* func foo() (X, bool, int)
* func foo() (*float64, *X, error)
Fixesgolang/go#38589
Change-Id: I8840d667437300fd1250a13630e12a36601f0a60
GitHub-Last-Rev: 581d810af959f8b2c0bf62a22e5725f32947f5e4
GitHub-Pull-Request: golang/tools#311
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313093
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>
Leave the options flag so people can disable it for now if needed.
Updates golang/go#39507.
Change-Id: I78bbac157caa18c5d9a8e2ffe1a5c5eba4c6c30f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317389
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: Peter Weinberger <pjw@google.com>
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>
Provide some support for template files, implementing most of
https://docs.google.com/document/d/1clKAywucZVBXvL_v4mMhLQXso59lmQPMk1gtSpkV-Xw
Template support is controlled by the option 'experimentalTemplateSupport'
which defaults to false.
Most of the code is in a new 'template' package. Implemented are
semantic tokens, diagnostics, definitions, hover, and references,
and there is a stub for completions.
This code treats all the template files of a package together, so as
to follow cross-references.
Change-Id: I793606d8a0c9e96a0c015162d68f56b5d8599294
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297871
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>
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>
Calling PackagesForFile on builtin.go loads is at a
command-line-arguments package, which has many type checking errors.
Add a new snapshot method IsBuiltin, which is used to avoid calling
PackagesForFile on builtin.go when diagnosing changed files or checking
for orphaned files. There may be other places where this should be used,
but this functionality can't reasonably be pushed down, as
PackagesForFile should always return something.
This exacerbated an existing race to building the builtin, because
ast.NewPackage unfortunately mutates the ast.File. Fix this by just
building the builtin package directly when building the handle. It
should be very fast.
Fixesgolang/go#44866
Change-Id: Ie6c07478493fa011e92e6966289c2fa822d87b35
Reviewed-on: https://go-review.googlesource.com/c/tools/+/314290
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>
Due to the limitations of comments in ast, it is difficult to move
comments. The extract function feature currently does not handle
comments at all. This change instead prints the comments that would
have been lost above the call to the function, so that the user can
easily recover them. Otherwise, it was possible for users to lose
comments and not notice.
Updates golang/go#37170
Change-Id: I1e2d865f5deddefbb0417732490decbdfcde5f3d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/313211
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>
It wasn't obvious that there are two different kind of diagnostics
reported by fieldalignment, one for struct size and another for pointer
bytes.
The documentation now mentions both types, and shows an example that
clarify what "pointer bytes" are.
Fixesgolang/go#45541
Change-Id: Ia62fb05980ddddf52e579ac51459aaaed168cfa7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/314469
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
If there is a return statement that is guaranteed to execute in
the selection to extract to function, then the result of calling
the extracted function can be directly returned.
Updates golang/go#37170
Change-Id: I6454e4107d670e4a1bc9048b2e1073fc80fc78ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312469
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>
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>
The utility of the debug server is limited by the requirement to start
gopls with the `-debug` flag and then look in the logs to see which port
the debug server is bound to.
This CL adds a new custom command `gopls.startDebugging` to start the
debug server on demand if it isn't already running, and return its debug
address. It also does some gymnastics to make this turn on debugging for
any intermediate gopls forwarders, when using daemon mode.
For golang/go#45518
Change-Id: I48a90088f96aca54f34f93bedbfe864515320f61
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309409
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>
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>
We still hear from users for whom gopls uses too much memory. My efforts
to reduce memory usage while maintaining functionality are proving
fruitless, so perhaps it's time to accept some functionality loss.
DegradeClosed MemoryMode typechecks all packages in ParseExported mode
unless they have a file open. This should dramatically reduce memory
usage in monorepo-style scenarious, where a ton of packages are in the
workspace and the user might plausibly want to edit any of them.
(Otherwise they should consider using directory filters.)
The cost is that features that work across multiple packages...won't.
Find references, for example, will only find uses in open packages or in
the exported declarations of closed packages.
The current implementation is a bit leaky; we keep the ParseFull
packages in memory even once all their files are closed. This is related
to a general failure on our part to drop unused packages from the
snapshot, so I'm not going to try to fix it here.
Updates golang/go#45457, golang/go#45363.
Change-Id: I38b2aeeff81a1118024aed16a3b75e18f17893e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310170
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@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>
The previous fix (d1362d7) is not sufficient for all cyclic types.
This change updates Deref function to support more complex cases.
We use a map with underlying types to detect cycles.
Fixesgolang/go#45510
Change-Id: I28f655a9c1d4f363cb7ae3f47db3e8567fe6e80a
GitHub-Last-Rev: 4c898741c0cf07cb765b759b1edf15e004fc1a0e
GitHub-Pull-Request: golang/tools#305
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310311
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>
Return a pointer type if the type refers to itself (for example, type a *a).
Fixesgolang/go#45510
Change-Id: Ifaf9c0fe9df8a1cab300479394a7127dfb820a88
GitHub-Last-Rev: 009802341673cfd24c04d6a115a6082029dfa2a2
GitHub-Pull-Request: golang/tools#302
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310050
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Heschi Kreinick <heschi@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>
Always use (*ast.TypeSpec).Type as a HoverInformation source.
Store a type name and an indication of whether it's a type alias
declaration as fields of HoverInformation.
Fixesgolang/go#45261
Change-Id: Ifbcdc15990379d0c73a419dd6cdf175d53dce925
GitHub-Last-Rev: 556dc94ab7d59fd251bbe0a537b19bc0fd7dd544
GitHub-Pull-Request: golang/tools#293
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305189
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Don't use GetParsedFile because it extracts a package with
TypecheckWorkspace mode, but we want to support std and
3rd-party packages. So, we reuse the content of GetParsedFile
directly in Highlight function with TypecheckFull mode.
Fixesgolang/go#43511
Change-Id: Ibd1d42e28a6739ba011113df0e6e7e98d1b86eb5
GitHub-Last-Rev: 3746092210a38ec152faf26c84f6b0a8bb9f0d25
GitHub-Pull-Request: golang/tools#298
Reviewed-on: https://go-review.googlesource.com/c/tools/+/307171
Trust: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
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>
Go to Type Definition works for all composite types except maps because
it is not clear which type to return if both key and value are named types.
Fixesgolang/go#45029
Change-Id: Ie14f333c51af11033e2494aaaac367d35e7dc87b
GitHub-Last-Rev: 94a04812eafe8c157819f0155ed7be2779437867
GitHub-Pull-Request: golang/tools#292
Reviewed-on: https://go-review.googlesource.com/c/tools/+/304789
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There are 2 different anonymous struct declarations that require
different approaches:
1. var x struct{...}
2. x := struct{...}{}
For the first one we can use the existing solution with a minor update.
However, it returns the wrong docs for the fields of nested structs.
To fix this we need to visit all fields recursively.
The second one is not a generic declaration. So, the simplest solution
is to use the method Snapshot.PosToField.
Fixesgolang/go#43675
Change-Id: I46685e7985cbf2c1c5b1b74ef3cd3a70b920feba
GitHub-Last-Rev: 8a5704c2ecc3f8a007c00c7adcd637e56d99106c
GitHub-Pull-Request: golang/tools#284
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300029
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Bryan C. Mills <bcmills@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>
The blank identifier is always a local variable. It can't be
a function parameter or a return value.
Fixesgolang/go#44813
Change-Id: Ieca9da35aaa9f5826ab89ded73702bed952e1226
GitHub-Last-Rev: bb7a2353ab64eed7f13bd5b9cb3b85d90b71c0ed
GitHub-Pull-Request: golang/tools#294
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305429
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>
Move postfix completion functionality behind an experimental option
flag. For now users can enable it by setting
"experimentalPostfixCompletions" or "allExperiments".
I added a RunnerOption so regtest tests can tweak *source.Options. I
didn't refactor the "Experimental" mode to use the new RunnerOption
because I didn't fully understand its purpose.
Change-Id: I75ed748710cae7fa99f4ea6ea117ce245a4e9749
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296109
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Postfix snippets are artificial methods that allow the user to compose
common operations in an "argument oriented" fashion. For example,
instead of "sort.Slice(someSlice, ...)" a user can expand
"someSlice.sort!". The snippet labels end in "!" to make it clearer
they do something potentially unexpected. The postfix snippets have
low scores so they should not interfere with normal completions.
The snippets are represented (almost) entirely as Go text/template
templates. This way the user can create custom snippets to match their
general preferences or to capture common patterns in their codebase.
There is currently no way for the user to create snippets, but it
could be accomplished with a configuration file, custom LSP command,
or similar.
I started by implementing a variety of snippets to help flesh out the
various facilities needed by the templates. The most interesting
template capabilities are:
- The ability to import packages as necessary (e.g. "sort" must be
imported to call sort.Slice()).
- The ability to generate unique variable names to avoid accidental
shadowing issues.
- The ability to weave LSP snippets into the template. Currently,
only {{.Cursor}} is exposed, which corresponds to the snippet's
final tab stop.
Briefly, these are the postfix snippets in this commit:
- foo.sort => sort.Slice(foo, func(...){}) (slices)
- foo.last => foo[len(foo)-1] (slices)
- foo.reverse (slices)
- foo.range => for i, v := range foo {} (slices/maps)
- foo.append
This snippet inserts a self-assignment append statement when
appropriate, otherwise just an append expression.
- foo.copy creates a copy of a slice
- foo.clear empties out a map
- foo.keys creates slice of keys
- foo().var assigns result value(s) to variables
- foo.print prints foo to stdout
Some of these are probably not very useful in practice, and I'm sure
there are lots of great ones I didn't think of.
Updates golang/go#39507.
Change-Id: I9ecc748aa79c0d47fa6ff72d4ea671e917a2d5d6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272586
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Muir Manders
Suzy Mueller
Rebecca Stambler
Karthik Nayak
OneOfOne
Dominik Honnef
Marwan Sulaiman
Shoshin Nikita
Rob Findley
Heschi Kreinick
Pen Tree
Peter Weinbergr
Pontus Leitzler