Invert "useDeepCompletions" config flag to "disableDeepCompletion" and
separate out "disableFuzzyMatching" which reverts to the previous
prefix matching behavior.
I separated fuzzy matching tests out to a separate file so they aren't
entangled with deep completion tests. In coming up with representative
test cases I found a couple issues which I fixed:
- We were treating a fuzzy matcher score of 0 as no match, but the
matcher returns 0 for candidates that match but have no bonuses. I
changed the matcher interface so that a score of 0 counts as a
match. For example, this was preventing a pattern of "o" from
matching "foo".
- When we lower a candidate's score based on its depth, we were
subtracting a static multiplier which could result in the score
going negative. A negative score messes up future score weighting
because multiplying it by a value in the range [0, 1) makes it
bigger instead of smaller. Fix by scaling a candidate's score based
on its depth rather than subtracting a constant factor.
Updates golang/go#32754
Change-Id: Ie6f9111f1696b0d067d08f7eed7b0a338ad9cd67
Reviewed-on: https://go-review.googlesource.com/c/tools/+/192137
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Deep completions can take a long time (500ms+) if there are many
large, deeply nested structs in scope. To make sure we return
completion results in a timely manner we now notice if we have spent
"too long" searching for deep completions and reduce the search scope.
In particular, our overall completion budget is 100ms. This value is
often cited as the longest latency that still feels instantaneous to
most people. As we spend 25%, 50%, and 75% of our budget we limit our
deep completion candidate search depth to 4, 3, and 2,
respectively. If we hit 90% of our budget, we disable deep completions
entirely.
In my testing, limiting the search scope to 4 normally makes even
enormous searches finish in a few milliseconds. Of course, you can
have arbitrarily many objects in scope with arbitrarily many fields,
so to cover our bases we continue to dial down the search depth as
needed.
I replaced the "enabled" field with a "maxDepth" field that disables
deep search when set to 0.
Change-Id: I9b5a07de70709895c065503ae6082d1ea615d1af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190978
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Optimize a few things to speed up deep completions:
- item() is slow, so don't call it unless the candidate's name matches
the input.
- We only end up returning the top 3 deep candidates, so skip deep
candidates early if they are not in the top 3 scores we have seen so
far. This greatly reduces calls to item(), but also avoids a
humongous sort in lsp/completion.go.
- Get rid of error return value from found(). Nothing checked for this
error, and we spent a lot of time allocating the only possible error
"this candidate is not accessible", which is not unexpected to begin
with.
- Cache the call to types.NewMethodSet in methodsAndFields(). This is
relatively expensive and can be called many times for the same type
when searching for deep completions.
- Avoid calling deepState.chainString() twice by calling it once and
storing the result on the candidate.
These optimizations sped up my slow completion from 1.5s to
0.5s. There were around 200k deep candidates examined for this one
completion. The remaining time is dominated by the fuzzy
matcher. Obviously 500ms is still unacceptable under any
circumstances, so there will be subsequent improvements to limit the
deep completion search scope to make sure we always return completions
in a reasonable amount of time.
I also made it so there is always a "matcher" set on the
completer. This makes the matching logic a bit simpler.
Change-Id: Id48ef7031ee1d4ea04515c828277384562b988a8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190522
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
this moves the actual diff algorithm into a different package and then provides hooks so it can be easily replaced with an alternate algorithm.
Change-Id: Ia0359f58878493599ea0e0fda8920f21100e16f1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190898
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Unimported packages may be suggested as completion items. Since these
are not yet imported, they should be ranked lower than other candidates.
They also require an additional import statement to be valid, which is
provided as an AdditionalTextEdit.
Adding this import does not use astutil.AddNamedImport, to avoid
editing the current ast and work even if there are errors. Additionally,
it can be hard to determine what changes need to be made to the source
document from the ast, as astutil.AddNamedImport includes a merging
pass. Instead, the completion item simply adds another import
declaration.
Change-Id: Icbde226d843bd49ee3713cafcbd5299d51530695
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190338
Run-TryBot: Suzy Mueller <suzmue@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This is a straight move of some code with no changes.
It splits the part of the telemetry code that will become a standalone library from the bit that belongs in the lsp.
Change-Id: Icedb6bf1f3711da9251450531729984df6df7787
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190403
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make use of the existing fuzzy matcher to perform server side fuzzy
completion matching. Previously the server did exact prefix matching
for completion candidates and left fancy filtering to the
client. Having the server do fuzzy matching has two main benefits:
- Deep completions now update as you type. The completion candidates
returned to the client are marked "incomplete", causing the client
to refresh the candidates after every keystroke. This lets the
server pick the most relevant set of deep completion candidates.
- All editors get fuzzy matching for free. VSCode has fuzzy matching
out of the box, but some editors either don't provide it, or it can
be difficult to set up.
I modified the fuzzy matcher to allow matches where the input doesn't
match the final segment of the candidate. For example, previously "ab"
would not match "abc.def" because the "b" in "ab" did not match the
final segment "def". I can see how this is useful when the text
matching happens in a vacuum and candidate's final segment is the most
specific part. But, in our case, we have various other methods to
order candidates, so we don't want to exclude them just because the
final segment doesn't match. For example, if we know our candidate
needs to be type "context.Context" and "foo.ctx" is of the right type,
we want to suggest "foo.ctx" as soon as the user starts inputting
"foo", even though "foo" doesn't match "ctx" at all.
Note that fuzzy matching is behind the "useDeepCompletions" config
flag for the time being.
Change-Id: Ic7674f0cf885af770c30daef472f2e3c5ac4db78
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190099
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change eliminates the need for the package cache map, and instead
stores package type information in the store. We still have to maintain
invalidation logic because the key is not computed correctly.
Change-Id: I1c2a7502b99491ef0ff68d68c9f439503d531ff1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/185438
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This relates to https://github.com/golang/go/issues/31374 and should switch all instances within `gopls` to use `x/errors` instead of `fmt` to create new errors.
Change-Id: I18339b75d12418d852e0dcc2ba0ed6c2970783b3
GitHub-Last-Rev: f4a55d9b79e7458ef1f1e06cb5eabbabd884f321
GitHub-Pull-Request: golang/tools#108
Reviewed-on: https://go-review.googlesource.com/c/tools/+/179880
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change removes the need for the ast and token fields on the *goFile
object. We switch to using source.ParseGoHandles on the package, which
means that we can easily access both the AST and token via the package,
which is already cached.
Change-Id: I5f78bbe09362f4d95eb15556617bdbd809a7a55d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/185878
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
also change the return type to be and end function and not an incomplete span
Change-Id: Icd99d93ac98a0f8088f33e905cf1ee3fe410c024
Reviewed-on: https://go-review.googlesource.com/c/tools/+/185349
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds documentation to the completion items. This normally
should be done in completionItem/resolve, since it takes more time to
compute documentation. However, I am not sure if that latency incurred
by pre-computing documentation is actually significantly more than the
latency incurred by an extra call to 'completionItem/resolve'. This
needs to be investigated, so we begin by just precomputing all of the
documentation for each item.
Updates golang/go#29151
Change-Id: I148664d271cf3f1d089c1a871901e3ee404ffbe8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/184721
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This uses the new opencensus compatability layer to add telementry to some of
the functions in the lsp, in order to allow us to understand their costs and
call patterns.
Change-Id: I7df820cd4eace7a4840ac6397d5df402369bf0a7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/183419
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Add some extra smarts when evaluating untyped constants as completion
candidates. Previously we called types.Default() on the expected type
and candidate type, but this loses the untypedness of an untyped
constant which prevents it from being assignable to any type or named
type other than the untyped constant's default type.
Note that the added logic does not take into account the untyped
constant's value, so you will still get some false positive
completions (e.g. suggesting an untyped negative integer constant when
only a uint would do). Unfortunately go/types doesn't provide a way of
answering the question "is this *types.Const assignable to this
types.Type" since types.AssignableTo only considers a constant's type,
not its value.
Change-Id: If7075642e928f712b127256ae7706a5190e2f42c
GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92
GitHub-Pull-Request: golang/tools#128
Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Deep completion refers to searching through an object's fields and
methods for more completion candidates. For example:
func wantsInt(int) { }
var s struct { i int }
wantsInt(<>)
Will now give a candidate for "s.i" since its type matches the
expected type.
We limit to three deep completion results. In some cases there are
many useless deep completion matches. Showing too many options defeats
the purpose of "smart" completions. We also lower a completion item's
score according to its depth so that we favor shallower options. For
now we do not continue searching past function calls to limit our
search scope. In other words, we are not able to suggest results with
any chained fields/methods after the first method call.
Deep completions are behind the "useDeepCompletions" LSP config flag
for now.
Change-Id: I1b888c82e5c4b882f9718177ce07811e2bccbf22
GitHub-Last-Rev: 26522363730036e0b382a7bcd10aa1ed825f6866
GitHub-Pull-Request: golang/tools#100
Reviewed-on: https://go-review.googlesource.com/c/tools/+/177622
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In type assertion expressions and type switch clauses we now infer the
type from which candidates must be assertable. For example in:
var foo io.Writer
bar := foo.(<>)
When suggesting concrete types we will prefer types that actually
implement io.Writer.
I also added support for the "*" type name modifier. Using the above
example:
bar := foo.(*<>)
we will prefer type T such that *T implements io.Writer.
Change-Id: Ib483bf5e7b339338adc1bfb17b34bc4050d05ad1
GitHub-Last-Rev: 965b028cc00b036019bfdc97561d9e09b7b912ec
GitHub-Pull-Request: golang/tools#123
Reviewed-on: https://go-review.googlesource.com/c/tools/+/183137
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds supports for a package belonging to multiple files.
It requires additional packages.Loads for all of the packages to which a
file belongs (for example, if a non-test file also belongs to a package's
test variant).
For now, we re-run go/packages.Load for each file we open, regardless of
whether or not we already know about it.
This solves the issue of packages randomly belonging to a test or not.
Follow-up work needs to be done to support multiple packages in
references, rename, and diagnostics.
Fixesgolang/go#32791Fixesgolang/go#30100
Change-Id: I0a5870a05825fc16cc46d405ef50c775094b0fbb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/183628
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change just separates minor changes made along the course of the
memoization CL out into their own change. This will clean up the diffs
in the memoization CL.
Change-Id: I7d59e05ba6472af5f1bf516b1e5b879a5815b9a5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/183250
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Previously we would always expand *types.Func completion candidates to
function calls, even if the expected type matched the function itself,
not its return value. Now we check the function itself before we check
its return value. This fixes cases like this:
func foo() int { return 0 }
var f func() int
f = <foo> // now completes to "foo" instead of "foo()"
Also, *types.Var function values were never getting expanded to calls.
I fixed the completion formatting to know that both *types.Func
and *types.Var objects might need to be invoked in the completion
item. This fixes cases like this:
foo := func() int { return 0 }
var i int
i = <foo()> // now completes to "foo()" instead of "foo"
Change-Id: I8d0e9e2774f92866a3dd881092c13019fb3f3fd5
GitHub-Last-Rev: 7442bc84b5bbb86296289bbc745ec56a5f89d901
GitHub-Pull-Request: golang/tools#122
Reviewed-on: https://go-review.googlesource.com/c/tools/+/182879
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In situations like:
var buf bytes.Buffer
var w io.Writer = &b<>
if we want to complete to "buf" properly we need to apply the "&" type
modifier to buf's type of bytes.Buffer to see that it is assignable
to type io.Writer. Previously we applied type modifiers in reverse to
the "expected" type (io.Writer in this case), but that is obviously
incorrect in this situation since it is nonsensical to
dereference (the reverse of "&") io.Writer.
Change-Id: Ib7ab5761f625217e023286384c23b8c60e677aac
GitHub-Last-Rev: 4be528f2572c9c987334552e3f8a31d4eddce81a
GitHub-Pull-Request: golang/tools#121
Reviewed-on: https://go-review.googlesource.com/c/tools/+/182598
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When checking if a completion candidate matches the expected type at
the cursor position, we now use types.AssignableTo instead of
types.Identical. This properly handles cases like using a concrete
type to satisfy an interface type.
Calling AssignableTo triggered some crashes related to the fake
"resolved" types we create. Their underlying type was nil, which is
not allowed. We now set their underlying type to the invalid type.
I've also rearranged things so expected type information lives in a
dedicated typeInference struct. For now there is no new information added,
but in subsequent commits there will be more metadata about the
expected type.
Change-Id: I14e537c548960c30e444cf512a4413d75bb3ee45
GitHub-Last-Rev: 7e64ebe32938562648938d7a480195d954b018f2
GitHub-Pull-Request: golang/tools#116
Reviewed-on: https://go-review.googlesource.com/c/tools/+/182358
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This moves the fileset down to the base cache, the overlays down to the session
and stores the environment on the view.
packages.Config is no longer part of any public API, and the config is build on
demand by combining all the layers of cache.
Also added some documentation to the main source pacakge interfaces.
Change-Id: I058092ad2275d433864d1f58576fc55e194607a6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/178017
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Completions like "foo.Bar(baz.<>)" were replacing one too many
characters resulting in "foo.Bar(baz.Qux()". This is because the go
parser adds a phantom "_" identifier when parsing "foo.". We thought
the "_" was really there, so we were issuing text edits to replace
it. Fix by ignoring "_" selectors when the cursor is positioned to
their left.
Fixesmicrosoft/vscode-go#2525
Change-Id: I1233a9d6275e2a79b666ca0230862238160b4aab
GitHub-Last-Rev: de9a3f00187b1b9bfcc4e497461f4602ae6f8923
GitHub-Pull-Request: golang/tools#104
Reviewed-on: https://go-review.googlesource.com/c/tools/+/178217
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The insertion range for completion items was not right. The range's
end was 1 before the start. Fix by taking into account the length of
the prefix when generating the range start and end.
Now instead of a "prefix", we track the completion's
"surrounding". This is basically the start and end of the abutting
identifier along with the cursor position. When we insert the
completion text, we overwrite the entire identifier, not just the
prefix. This fixes postfix completion like completing "foo.<>Bar" to
"foo.BarBaz".
Fixesgolang/go#32078Fixesgolang/go#32057
Change-Id: I9d065a413ff9a6e20ae662ff93ad0092c2007c1d
GitHub-Last-Rev: af5ab4d60566bf0589d9a712c80d75280178cba9
GitHub-Pull-Request: golang/tools#103
Reviewed-on: https://go-review.googlesource.com/c/tools/+/177757
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Calculate expected type in the following cases:
- switch case statements
- index expressions (e.g. []int{}[<>] or map[string]int{}[<>])
- slice expressions (e.g. []int{}[1:<>])
- channel send statements
- channel receive expression
We now also prefer type names in type switch clauses and type asserts.
Change-Id: Iff8c317a9116868b36701d931c802d9147f962d8
GitHub-Last-Rev: e039a45aebe1c6aa9b2011cad67ddaa5e4ed4d77
GitHub-Pull-Request: golang/tools#97
Reviewed-on: https://go-review.googlesource.com/c/tools/+/176941
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This abstracts out the concrete file type so that we can support non go files.
Change-Id: I7447daa2ce076ec2867de9e59a0dedfe1a0553f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/175217
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
After some discussion about how to handle insert and filter text
(https://github.com/microsoft/vscode-languageserver-node/issues/488), it
seems that it is better practice to overwrite the prefix in completion
items, rather than trimming the prefix from the insert text.
Change-Id: I7c794b4b1d4518af31e7318a283aa3681a0cf66a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/176958
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Fix the following issues:
- We were trying to complete struct literal field names for
selector expressions (e.g. "Foo{a.B<>}"). Now we only complete field
names in this case if the expression is an *ast.Ident.
- We weren't including lexical completions in cases where you might be
completing a field name or a variable name (e.g. "Foo{A<>}").
I refactored composite literal logic to live mostly in one place. Now
enclosingCompositeLiteral computes all the bits of information related
to composite literals. The expected type, completion, and snippet code
make use of those precalculated facts instead of redoing the work.
Change-Id: I29fc808544382c3c77f0bba1843520e04f38e79b
GitHub-Last-Rev: 3489062be342ab0f00325d3b3ae9ce681df7cf2e
GitHub-Pull-Request: golang/tools#96
Reviewed-on: https://go-review.googlesource.com/c/tools/+/176601
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Improve expected type determination for the following cases:
- search back further through ast path to handle cases where the
position's node is more than two nodes from the ancestor node with
type information
- generate expected type for return statements
- wrap and unwrap pointerness from expected type when position is
preceded by "*" (dereference) or "&" (reference) operators,
respectively
- fix some false positive expected types when completing the "Fun"
(left) side of a CallExpr
Change-Id: I907ee3e405bd8420031a7b03329de5df1c3493b9
GitHub-Last-Rev: 20a0ac9bf2b5350494c6738f5960676cc50fb454
GitHub-Pull-Request: golang/tools#93
Reviewed-on: https://go-review.googlesource.com/c/tools/+/174477
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change uses an *ast.Package built from the file
go/src/builtin/builtin.go. Completion (and ultimately other features)
will be resolved using this AST instead of being hardcoded.
Change-Id: I3e34030b3236994faa484cf17cf75da511165133
Reviewed-on: https://go-review.googlesource.com/c/tools/+/174381
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Now when you accept a struct literal field name completion, you will
get a snippet that includes the colon, a tab stop, and a comma if
the literal is multi-line. If you have "gopls.usePlaceholders"
enabled, you will get a placeholder with the field's type as well.
I pushed snippet generation into the "source" package so ast and type
info is available. This allows for smarter, more context aware snippet
generation. For example, this let me fix an issue with the function
snippets where "foo<>()" was completing to "foo(<>)()". Now we don't
add the function call snippet if the position is already in a CallExpr.
I also added a new "Insert" field to CompletionItem to store the plain
object name. This way, we don't have to undo label decorations when
generating the insert text for the completion response. I also changed
"filterText" to use this "Insert" field since you don't want the
filter text to include the extra label decorations.
Fixesgolang/go#31556
Change-Id: I75266b2a4c0fe4036c44b315582f51738e464a39
GitHub-Last-Rev: 1ec28b2395c7bbe748940befe8c38579f5d75f61
GitHub-Pull-Request: golang/tools#89
Reviewed-on: https://go-review.googlesource.com/c/tools/+/173577
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change separates the completion formatting functions from the
completion logic. It also simplifies the completion logic by necessary
values per-request into a struct that is used throughout.
Change-Id: Ieb6b09b7076ecf89c8b76ec12c1f1c9b10618cfe
Reviewed-on: https://go-review.googlesource.com/c/tools/+/173779
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Completion suppression in comments wasn't working for comments in
switch case statements, select case statements, and decl statements.
Rather than adding those to the list of leaf ast.Node types to look
for, we now always check if the position is in a comment. This fix
broke some completion tests that were using re"$" since "$" matches
after the comment "//" characters.
We now also don't complete within any literal values. Previously we
only excluded string literals.
Change-Id: If02f39f79fe2cd7417e39dbac2c6f84a484391ec
GitHub-Last-Rev: 7ab3f526b6752a8f74413dcd268382d359e1beba
GitHub-Pull-Request: golang/tools#88
Reviewed-on: https://go-review.googlesource.com/c/tools/+/173518
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
When the value of a composite literal key/value pair was unparsable,
you were getting completions for the composite literal keys instead of
values. For example "struct { foo int }{foo: []<>" was completing to
the field name "foo". This was because the leaf ast.Node at the cursor
was the composite literal itself, and our go-back-one-character logic
was not happening because the preceding character's node
was *ast.BadExpr, not *ast.Ident. Fix by always generating the ast
path for the character before the cursor's position. I couldn't find
any cases where this broke completion.
I also added expected type detection for the following composite
literal cases:
- array/slice literals
- struct literals (both implicit and explicit field names)
- map keys and values
Fixesgolang/go#29153
Change-Id: If8cf678cbd743a970f52893fcf4a9b83ea06d7e9
GitHub-Last-Rev: f385705cc05eb98132e20561451dbb8c39b68519
GitHub-Pull-Request: golang/tools#86
Reviewed-on: https://go-review.googlesource.com/c/tools/+/173099
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
- show signature for function calls whose function expression is not
an object (e.g. the second call in foo()()). since the function name
is not available, we use the generic "func"
- only provide signature help when the position is on or within the
call expression parens. this is consistent with the one other lsp
server i tried (java). this improves the gopls experience in emacs
where lsp-mode is constantly calling "hover" and
"signatureHelp" ("hover" should be preferred unless you are inside
the function params list)
- use the entire signature type string as the label since that includes
the return values, which are useful to see
- don't qualify the function name with its package. it looks funny to
see "bytes.Cap()" as the help when you are in a call
to (*bytes.Buffer).Cap(). it could be useful to include invocant
type info, but leave it out for now since signature help is meant to
focus on the function parameters.
- don't turn variadic args "foo ...int" into "foo []int" for the
parameter information (i.e. maintain it as "foo ...int")
- when determining active parameter, count the space before a
parameter name as being part of that parameter (e.g. the space
before "b" in "func(a int, b int)")
- handle variadic params when determining the active param (i.e.
highlight "foo(a int, *b ...string*)" on signature help for final
param in `foo(123, "a", "b", "c")`
- don't generate an extra space in formatParams() for unnamed
arguments
I also tweaked the signatureHelp server log message to include the
error message itself, and populated the server's logger in lsp_test.go
to aid in development.
Fixesgolang/go#31448
Change-Id: Iefe0e1e3c531d17197c0fa997b949174475a276c
GitHub-Last-Rev: 5c0b8ebd87a8c05d5d8f519ea096f94e89c77e2c
GitHub-Pull-Request: golang/tools#82
Reviewed-on: https://go-review.googlesource.com/c/tools/+/172439
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL ensures that a "." inside a string literal will return an empty
completion list.
Fixesgolang/go#30477
Change-Id: I1442d0acab4c12a829047805f745c4729d69c208
Reviewed-on: https://go-review.googlesource.com/c/tools/+/167857
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
This change brings back handling for circular imports, which was removed
because I originally thought that go/packages would handle that.
However, since we are type-checking from source, we still end up having
to deal with that.
Additionally, we propagate the errors of type-checking to the
diagnostics so that the user can actually see some of the problems.
Change-Id: I0139bcaae461f1bcaf95706532bc5026f2430101
Reviewed-on: https://go-review.googlesource.com/c/tools/+/166882
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change adds a Package interface to the source package, which allows
us to reduce the information cached per-package (we don't use any of the
unnecessary fields in a *go/packages.Package).
This change also adds an analysis cache for each package, which is used
to cache the results of analyses to avoid recomputation.
Change-Id: I56c6b5ed51126c27f46731c87ac4eeacc63cb81a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/165750
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change adds an additional cache for type information, which here is
just a *packages.Package for each package. The metadata cache maintains
the import graph, which allows us to easily determine when a package X
(and therefore any other package that imports X) should be invalidated.
Additionally, rather than performing content changes as they happen, we
queue up content changes and apply them the next time that any type
information is requested.
Updates golang/go#30309
Change-Id: Iaf569f641f84ce69b0c0d5bdabbaa85635eeb8bf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/165438
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
we don't really use them, only generate them in cases where the failure is way more fundamental, and then also fail
to remember them for the next call to the same accessor. Better to not have them.
Change-Id: I0e8abeda688f5cc2a932ed95a80d89225c399f93
Reviewed-on: https://go-review.googlesource.com/c/162399
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The previous change (https://go-review.googlesource.com/c/tools/+/157678) only stopped completion in comments in global scope. This change prevents completions results from being sent for comments inside of functions.
Fixesgolang/go#29370
Change-Id: I2b43ae2942c6ce7376d2a5f88c40e6ac45c2b773
GitHub-Last-Rev: bc4aac1370aa5758941cdfae63290f061a55e204
GitHub-Pull-Request: golang/tools#71
Reviewed-on: https://go-review.googlesource.com/c/158538
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
