The fuzzy matcher doc string says that it returns 0 on no match, but
this is in fact not true: it returns -1 on no match.
0 makes more sense, so fix the implementation rather than the docstring.
Change-Id: I997a6b5dcb1d7c25cc73b2c236d24647f9326c80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248417
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This code seems to be duplicate of L509-L522 in this CL. It doesn't
affect the results of completion in any way since we already return
early from where we can.
Change-Id: I30ee1c94e58860f86d773d46cb1e527b2e646ef4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/251261
Run-TryBot: Danish Dua <danishdua@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is based on Paul Jolly's CL 228760, updated to use the new cache
API, support the symbolStyle configuration option, and lift up the
concept of symbol score for later improvement.
From that CL:
There are a number of issues with the current implementation:
* test variant packages are not handled correctly, meaning duplicate
symbols are returned
* fuzzy results are not ordered by score
We refactor the implementation of workspace symbol to use a
symbolCollector that carries context during the walk for symbols. As
part of resolving the test variant issue, we first determine a list of
packages to walk.
(*symbolCollector).collectPackages gathers the packages we are going to
inspect for symbols. This pre-step is required in order to filter out
any "duplicate" *types.Package. The duplicates arise for packages that
have test variants. For example, if package mod.com/p has test files,
then we will visit two packages that have the PkgPath() mod.com/p: the
first is the actual package mod.com/p, the second is a special version
that includes the non-XTest _test.go files. If we were to walk both of
of these packages, then we would get duplicate matching symbols and we
would waste effort. Therefore where test variants exist we walk those
(because they include any symbols defined in non-XTest _test.go files).
One further complication is that even after this filtering, packages
between views might not be "identical" because they can be built using
different build constraints (via the "env" config option). Therefore on
a per view basis we first build up a map of PkgPath() -> *types.Package
preferring the test variants if they exist. Then we merge the results
between views, de-duping by *types.Package.
Finally, when we come to walk these packages and start gathering
symbols, we ignore any files we have already seen (due to different
*types.Package for the same import path as a result of different build
constraints), keeping track of those symbols via symbolCollector.
Then we walk that list of packages in much the same way as before.
For golang/go#40548
Co-authored-by: Paul Jolly <paul@myitcv.io>
Change-Id: I8af5bdedbd4a6c3631a213d73a735aea556a13ae
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247818
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds completion within import blocks. Completions are suggested by directory depth of import so end user isn't shown a large list of possible imports at once. As an example, searching import for prefix "golang" would suggest "golang.org/" and then subdirectories under that (ex: "golang.org/x/"") on successive completion request and so on until a complete package path is selected.
Change-Id: I962d32f2b7eef2c6b2ce8dc8a326ea34c726aa36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250301
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Add additional benchmarks following the pattern of symbol benchmarks.
One for initial workspace load, and another for completion.
Change-Id: Iba826b188cb81dffabb1b08287dc7b76250dc54c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250802
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The origin and meaning of error messages in IDEs is sometimes obscure.
For instance "unexpected config annotations\nSource: Go (extension)" in vscode has an ambiguous Source, and it's not clear what config annotations
are being referred to. This CL would change the first part of that
message to "unexpected gopls setting 'annotations', making clear that
the message is from gopls (and not the Go extension shim), and that the
suspect value is 'annotations' itself.
Change-Id: Ia79534859fe101e6fbbd660bf426e2c1ac619b7f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/251078
Run-TryBot: Peter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds a test for this case (empty test file in GOPATH mode)
to go/packages. It is skipped for now, as the go/packages work-around is
too brittle to justify adding. Instead, we suppress gopls-generated
error messages in pop-ups--users should only see error messages if they
come from go/packages.
Fixesgolang/go#40825
Change-Id: I0e2af53578d65739ebae582075498d997fc019d7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250949
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The redirect to drop index.html must be done using r.URL.Path,
not relpath, because those might differ. Cutting len("index.html")
bytes off a string that doesn't end in index.html is incorrect.
While we're here, silence an annoying log print during go test.
For golang/go#40665.
Change-Id: I36553b041f53eab9c42da6b77184e90800a97e92
Reviewed-on: https://go-review.googlesource.com/c/tools/+/251080
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Seems we've drifted a bit from go1.12 support, mostly due to error
wrapping.
Fix this, as well as some assorted other failures.
I haven't tested 1.12 interactively.
For golang/go#39146
Change-Id: Id347ead2a13e89b76d2ae0047750e6b6b49911eb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250941
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
It's pretty easy to add an LSP benchmark using the regtests, provided we
run the benchmark ourselves from inside the runner. Do this for
workspace symbols to start, though we should add several of these.
Also fix some error messages when setting options.
Change-Id: Iab134018edec8837e90a0a926ec2e73addf95bb3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250798
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We should make sure to return deterministic results for these requests.
Fixesgolang/go#40904
Change-Id: If10489e3eca0e1b6a5e449de851d332f2d91ceb4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250737
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Period triggered completions don't provide any use in comments and in
worst case can be nuisance. LSP provides a completion context which
provides more info about what triggered a completion and hence we can
use this to ignore period triggererd completions. This will also provide
us options to deal with retriggered completions etc. better in the
future.
Change-Id: I8449aee0fe3cf5f9acf315865ac854d5c894d044
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250337
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Use space characters instead of the HTML " " character. VS Code and
other clients treat this character differently from a space, so it
results in different formatting. See
https://github.com/golang/go/issues/40947#issuecomment-680497904 for an
image with the difference.
Fixesgolang/go#40947
Change-Id: Ia78cb3ba82dcca8303d1b5a0a6d359a3eaca837c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/250697
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Span treats an end of file as the beginning of the next line, which for a final line ending without a newline is incorrect and leads to completions being ignored. We adjust the ending in case range end is on a different line here.
Change-Id: Ic545dcb221493530b7e39d2be8eba57b69fb6597
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249706
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Since we used to manually set surrounding for comments (instead of using
setSurrounding with an ident), the matched was never initialized and
hence we had to manually do prefix matching. We now initialize matcher
from setSurroundingForComment too.
Change-Id: I8aa735933ebba2fe493182e4245de668997ef7af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249707
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Fillstruct wasn't able to fill structs with fileds that held anonymous
structs or maps with anonymous structs/interfaces.
By adding *types.Struct and *types.Interface support in TypeExpr(),
fillstruct is now works for those as well.
Fixesgolang/go#40980
Change-Id: I2a1d6d4db237800197cf14e3ad5067a0e7ab701a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249999
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If an analyzer doesn't return error, and doesn't have any suggested
fixs either gopls panics. Return an empty set of edits instead.
Change-Id: I1cd812fedcbd2ddc01229f48c0cc4467ee3f0105
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249998
Reviewed-by: Robert Findley <rfindley@google.com>
Avoid logging to stderr as it will interfere with LSP communication.
Change-Id: Ic9ff4f3555eabb8b0b6503650df7de5ddb76ef98
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249997
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
packages.Load returns bad data for an empty xtest in GOPATH mode.
Updates golang/go#40825.
Change-Id: Ibab8dcbeafc22a71a2a4c3be0008b728c13c4c80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249703
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* adds support for comment completion inside declarations
* improves scoring for completion results for comments
* adds comment completion support for non-exported symbols
* adds pruning for results that don't match text surrounding cursor
* tests for comment completion
Change-Id: Icb445a469cee3122fe032630bee037c7bdfe2e18
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249639
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
formatZeroValue is currently only used when formatting return values for
statement completion. Per golang/go#40956, it must be possible to hit
this codepath with an invalid type.
In this case, the empty string seems like a reasonable value. Perhaps we
could do better, but fix the panic for now.
Fixesgolang/go#40956
Change-Id: I45b559d41001c857cef34aea2a5ac4a9096fe950
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249818
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Fix completion in the following cases:
type foo struct{}
// now we offer "&foo" instead of "foo"
var _ *foo = fo<>{}
struct { f *foo }{
// now we offer "&foo" instead of "*foo"
f: fo<>{},
}
Composite literal type names are a bit special because they are part
of an arbitrary value expression rather than just a standalone type
name expression. In particular, they can be preceded by "&", which
affects how they relate to the surrounding context. The "&" doesn't
technically apply to the type name, but we must take it into account.
I made three changes to fix the behavior:
1. When we want to make a composite literal type name into a pointer,
we use "&" instead of "*".
2. Record if a composite literal type is already has a "&" so we don't
add it again.
3. Fix "var _ *foo = fo<>{}" to properly infer expected type of "*foo"
by not stopping at *ast.CompositeLit searching up AST path when the
position is in the type name (as opposed to within the curlies).
Change-Id: Iee828f259eb939646b68f5066614ea3a262585c2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247525
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There's a bunch of noise in regtest results related to the LSP forwarder
handshake.
lsprpc.StreamServer was already configurable to disable connection
logging in tests. Use this configuration to also disable handshake
logging.
Change-Id: I4b00e23d1f0bc6dc5fdd1f6f470f0b892c6791bc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249418
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change contains several improvements for progress reporting:
+ Consolidate the 'progressWriter' interface into the workDone
interface. Now all progress reporting should use workDone, and the
workDoneWriter struct is just an io.Writer adapter on top of
workDone.
+ Factor out the pattern of progress reporting, and use for all
asynchronous commands.
+ Make several commands that were previously synchronous async.
+ Add a test for cancellation when the WorkDone API is not supported.
+ Always report workdone progress using a detached context.
+ Update 'run tests' to use the -v option, and merge stderr and stdout,
to increase the amount of information reported.
+ Since $/progress reporting is now always run with a detached context,
the 'NoOutstandingWork' expectation should now behave correctly. Use
it in a few places.
A follow-up CL will improve the messages reported on command completion.
For golang/go#40634
Change-Id: I7401ae62f7ed22d76e558ccc046e981622a64b12
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248918
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
We now rank printf operand candidates according to the corresponding
formatting verb. We follow what fmt allows for the most part, but I
omitted some things because they are uncommon and would result in many
false positives, or didn't seem worth it to support:
- We don't prefer fmt.Stringer or error types for "%x" or "%X".
- We don't prefer pointers for any verbs except "%p".
- We don't prefer recursive application of verbs (e.g. we won't prefer
[]string for "%s").
I decided against sharing code with the printf analyzer. It was
tangled somewhat with go/analysis, and I needed only a very small
subset of the format parsing.
I tweaked candidate type evaluation to accommodate the printf hints.
We now skip expected type of "interface{}" when matching candidate
types because it matches everything and would always supersede the
coarser object kind checks.
Fixesgolang/go#40485.
Change-Id: I6440702e33d5ec85d701f8be65453044b5dab746
Reviewed-on: https://go-review.googlesource.com/c/tools/+/246699
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
qualifiedObjsAtProtocolPos returned too early. Have it keep looking in
the rest of the candidate packages.
This changes the returned error slightly but AFAICT nobody cares.
Updates golang/go#40809.
Change-Id: Ic8199a484f0abcaa48cb6a3bcdd782195802d670
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249637
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add a new autocomplete function that completes based on import path
prefix rather than package name prefix.
Updates golang/go#35877.
Change-Id: Ib768080ee99debfff1c8c870d22dc7b7459deadd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249419
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Danish Dua <danishdua@google.com>
* Adds outgoing calls call hierarchy for function declarations to gopls. Returns all call ranges and call items for functions/literals being called.
* Adds tests for outgoing call.
* Updates cmd to account for call ranges and call items being in different files for outgoing calls.
* Updates prepare call hierarchy to return declaration as root instead of cursor position.
Example:
Example shows https://github.com/golang/tools/blob/master/internal/lsp/source/call_hierarchy.go
Show Call Hierarchy View: https://imgur.com/a/DA5vc6l
Peek Call Hierarchy View: https://imgur.com/a/fuiG0Be
Note:
* While incoming calls for a function defined in an interface return references to that function, outgoing calls don't return anything since we don't know what implementation to return outgoing calls for.* Outgoing calls to function literals show as variable name used to define the literal, compared to <scope>.func() for incoming calls.
Change-Id: Ib8afbd8617675d12952db0b80170ada5988e90ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248537
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
When the client closes its connection, we get an EOF, but it's not
really an error. Suppress it so that the gopls binary doesn't exit with
an error.
In principle we should connect this to (lsp.Server).shutdown somehow,
but as far as I know a path for that doesn't exist, and this seems
pretty innocuous to me.
Fixesgolang/go#40832.
Change-Id: I9dd83d26bcf5c07e03188d3829e603005d80c8c4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249417
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 248380 forced all type checking to be in the default workspace mode.
In that CL, I said I couldn't think of any features that would break. It
appears I didn't think very hard. Navigation features inside of
dependencies are something I use all the time and they broke.
Reintroduce the ability to get packages in a particular mode, and make
it convenient to get them in all relevant modes. Update some critical
features to do so, and add regression tests.
Fixesgolang/go#40809.
Change-Id: I96279f4ff994203694629ea872795246c410b206
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249120
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Some Commands require that the buffer is saved before running them (i.e.
generate, test and toggle details). If the buffer isn't saved gopls
sends a ShowMessage request to the client. Before this change it
did not return any error from the ExecuteCommand request itself (unless
ShowMessage failed).
A progress token can be provided by the client as a part of the
ExecuteCommand request, and that is, according to the LSP spec one way
to start a WorkDoneProgress. At this point the client expects
that gopls send progress updates.
With this change, ExecuteCommand now return an error if the buffer
isn't saved, so that the client know that it shouldn't expect any
progress updates with this specific token.
Change-Id: I8a7af20a0c1532fc4ad03efd4e04bfb1a6871644
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248766
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
go mod tidy lens only shows up for a dirty mod file. Tidying a dirty
mod file makes the lens disappear.
Closesgolang/go#40422
Change-Id: I3356ffe94deaf7a5cdfc159c16470894336edf9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248717
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
CL 244117 introduced a bug when modFile == os.DevNull: v.root is left
uninitialized, resulting in a view that appears to own all files. Fixing
that exposes a problem where opening a folder with no Go files and
GO111MODULE=on shows a popup. Skip the popup when no Go files are found.
Change-Id: I7f8b2d6fd2f954af64c3a65156ff44c649f3a5b2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248620
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In this example:
p := &[]int{}
append([]int{}, *<>)
At <> we completed to "**p" instead of "*p...". There were two fixes:
1. builtinArgType() wasn't propagating the "modifiers", so we were
forgetting about the preceding "*" pointer indirection and
inserting it again with the completion. Fix by propagating
modifiers.
2. The candidate formatting responsible for adding "..." had over
simplified logic to determine if we are completing the variadic
param. Now instead the candidate evaluation code marks the
candidate as "variadic" so the formatting doesn't have to think at
all.
Change-Id: Ib71ee8ecfafb915df331f1d2e55b76f76a530243
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248018
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In the following example:
var foo []someStruct
foo = append(foo, <>)
we now downrank "foo" as a candidate at "<>". You very rarely append a
slice to itself, so having "foo" ranked highly was counterproductive.
Fixesgolang/go#40535.
Change-Id: Ic01366aeded4ba2b6b64bfddd33415499b35a323
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247519
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When a signature doesn't name its params, we make up param
names when generating a corresponding func literal:
var f func(myType) // no param name
f = fun<> // completes to "func(mt myType) {}"
Previously we would abbreviate named types and fall back to "_" for
builtins or repeated names. We would require placeholders to be
enabled when using "_" so the user could name the param easily. That
left users that don't use placeholders with no completion at all in
this case.
I made the following improvements:
- Generate a name for all params. For builtin types we use the first
letter, e.g. "i" for "int", "s" for "[]string". If a name is
repeated, we append incrementing numeric suffixes. For example,
"func(int, int32)" becomes "func(i1 int, i2 int32").
- No longer require placeholders to be enabled in any case.
- Fix handling of alias types so the param name and type name are
based on the alias, not the aliasee.
I also tweaked formatVarType to qualify packages using a
types.Qualifier. I needed it to respect a qualifier that doesn't
qualify anything so I could format e.g. "http.Response" as just
"Response" to come up with param names.
Fixesgolang/go#38416.
Change-Id: I0ce8a0a4e2485dda41a0aa696d9fd48bea595869
Reviewed-on: https://go-review.googlesource.com/c/tools/+/246262
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
* Adds incoming calls hierarchy to gopls. Returns function declarations/function literals/files enclosing the call/s to the function being inpected.
* Updates cmd to show ranges where calls to function in consideration are made by the caller.
* Added tests for incoming calls.
Example:
This example shows call hierarchy for PathEnclosingInterval in tools/go/ast/astutil.go
Show Call Hierarchy View: https://imgur.com/a/9VhspgA
Peek Call Hierarchy View: https://imgur.com/a/XlKubFk
Note:
* Function literals show up as <scope>.func() in call hierarchy since they don't have a name. Here scope is either the function enclosing the literal or a file for top level declarations
* Top level calls (calls not inside a function, ex: to initialize exported variables) show up as the file name
* Clicking on an item shows the the range where a call is made in the scope
Change-Id: I56426139e4e550dfabe43c9e9f1838efd1e43e38
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247699
Run-TryBot: Danish Dua <danishdua@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Every package has a default type checking mode dictated by whether it's
in the workspace or not. Some features force full rather than exported
type checking, but AFAICT that ends up being more harm than good. For
example, let's say we want to Find References on fmt.Printf in the stdlib.
Before this CL, we'd force a new type check of the fmt package, then
find no references because nothing else would have been checked against
that new version.
While there may be some features that work better in the current regime,
I can't think of any, and we have no test coverage for them. So I'd
rather start with what makes sense, and if we want to change it maybe
let's write some tests.
Change-Id: Iea589efb4b4374fd2a54451c868b6e2bd5484e20
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248380
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We failed to initialize the ProcessEnv when adding stdlib imports.
Somehow this went unnnoticed for a month or something. Initialize on
demand there too, and add a stronger check so there's a better error
message.
Fixesgolang/go#40670.
Change-Id: I391c115f417390be4a0e18f92fbfbcbfbdcc052c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/247797
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
While looking at Kubernetes I noticed that golang.org/x/text packages
were some of the largest. The problem is the large code-generated
tables, which use ellipsis array literals. Teach gopls to trim the cases
that matter there.
While silly, this trims ~60MB off the live heap, so I think it might be
worth it.
Change-Id: I0cfd80bd5fbc8703ac628312982af9c6ed871758
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248180
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Tweak a few things so that unnamed, non-basic types are offered as
completions in certain cases:
var _ []int = make(<>) // now properly suggests "[]int"
I also fixed type related keywords to not be offered if there is an
expected type:
var _ *int = new(<>) // don't offer "func", etc.
There are still some cases that don't work properly. For example:
var _ [][]int = make([]<>) // doesn't offer "[]int"
This would be harder to fix given the way things currently work.
Fixesgolang/go#40275, golang/go#40274.
Change-Id: I2577d5863d4757845ad3ff7dbb125106b649a6b6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/246360
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
