As an experiment, this CL introduces the first gopls feature that is
specific to generics: enriching function hover information with inferred
types. This is done with no additional gating on build constraints by
using the new internal/typeparams package.
The marker tests are updated to allow tests that rely on type parameters
being enabled.
Change-Id: Ic627d64b61a6211389196814edd0abe1484491eb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/317452
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>
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>
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>
For example:
type foo struct { i int }
type bar struct { i int }
var _ foo = <>
Previously at <> we would offer "bar{}" in addition to "foo{}" because
we knew "bar" was convertible to "foo". The "bar{}" completion wasn't
valid as inserted, however, because we didn't include the type
conversion. Anyway, it doesn't make sense to include convertible types
since the directly matching type should also be available. Fix by
tweaking the literal candidate code to skip candidates requiring
conversion.
Fixesgolang/go#46113.
Change-Id: Ica5e4af7f2f8bb2f7e2361efe39694f8bb738c97
Reviewed-on: https://go-review.googlesource.com/c/tools/+/319509
Run-TryBot: Muir Manders <muir@mnd.rs>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
This CL adds two new commands that let a client request a list of importable packages relative to a Go file and then select which import a programmer would like to add to said file.
Updates golang/go#43351
Change-Id: If12518874a92ed4167bdd711a92e03ee21c7b949
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281412
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
- Use func.FullName() everywhere we can, since simply Printf or Errorf is often ambiguous.
- Give more specific error output when unsupported %w directive is used.
Change-Id: Ic2b423d87f9bedde459c79ce5aae622e9a4b5266
Reviewed-on: https://go-review.googlesource.com/c/tools/+/301949
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
If A is a type, then in
type B {
A
} it is a type, but in
type C {
A int
}
it is a variable (and similarly in function types). The old code got this wrong.
Fixes: golang/go#46068
Change-Id: Ib7320914de81d2b7377214f53f99f4fea25e00fb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/318749
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
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>
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>
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>
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>
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>
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>
With unsafe.Slice about to be added, we'll get varying completions at
'unsafe.S_' depending on the Go version. Change the completion position
to be 'unsafe.Si_'.
Change-Id: Ib537fefceda7864b7a256565a3a7286d18e845c6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312470
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@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>
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>
xyz and err in
type A func(xyz int) (err error), or
type B struct{xyz int}
were incorrectly marked as types, when they are not.
These are now marked as variables (although the choice is somewhat
arbitrary for A).
Fixesgolang/go#45233
Change-Id: I2df4eab7606c356f30bf3337c12d9190e74bc392
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305209
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
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>
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>
This CL updates addErrCheckAndReturn to return "if err != nil { t.Fatal(err) }"
if the conditions for such snippet completion are met.The CL allows for
the following condition:
The enclosing functions takes a type that implements testing.TB which allows
for tests, benchmarks and extensions to the testing object to be completed.
Also, this CL doesn't explicitly check for the Test/Benchmark function
signature so that test helpers can also get the same benefits.
The remaining conditions for the current "if err != nil" checks also apply.
In the future, more testing completions UX can be added.
Fixesgolang/go#43310
Change-Id: I45197ab25610e31fef629394c79cb3792b532e7d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279488
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When parse errors occur, go's parse package cannot recover nicely.
gopls tried to compute folding ranges based on the partial info
in this case, but returning partial folding range info confuses
editors (vscode) and results in dropping previous folding range
info from the region after the parse error location.
This CL makes gopls not to return anything - so the editor can
tell the result is not believable and ignore it.
The ideal solution is to return a response explicitly surfacing
this case, but currently LSP (3.16, as of today) does not have
a way to describe this condition. See the discussion in
https://github.com/microsoft/language-server-protocol/issues/1200.
We also tried to make gopls return an error. While it worked
nicely in VSCode, we are not sure about how other editors handle
errors from foldingRange. So, instead, we just let gopls return
an empty result - since foldingRange is already broken in this
case, we hope it doesn't add a lot of noise to existing users.
VSCode Go will check the response from the middleware. If the
response is empty but the file is not empty, VSCode Go will
ignore the response.
(https://go-review.googlesource.com/c/vscode-go/+/299569)
Updates golang/vscode-go#1224
Updates golang/go#41281
Change-Id: I917d6667508aabbca1906137eb5e21a97a6cfdaf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291569
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The logic to extract the receiver identifier from a func decl was
incorrect, accepting only the common T and *T syntaxes, and panicking on
*(T).
Fix this by copying the logic from go/types.
Fixesgolang/go#44806
Change-Id: I1c87ab21ac04e484972bc4161180ca1112df3c73
Reviewed-on: https://go-review.googlesource.com/c/tools/+/298852
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>
The current hover information for constant time.Duration is not very
useful because it displays nanoseconds. So, show formatted duration
as an inline comment.
Fixesgolang/go#44667
Change-Id: I6177455fb8932d1914d5cf623c0d9c4eff8f0b3f
GitHub-Last-Rev: e168968012741a1e614c66bc97fe60b196943ed3
GitHub-Pull-Request: golang/tools#281
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297310
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For index expressions, optional "make" args, and composite literal
slice/array keys, we were inferring an expected type of int instead of
untyped int. This caused candidate rankings to not be quite right in
general, and in particular, after support for automatic type
conversions was added, the issue manifested as:
var foo []int
var bar int32
foo[ba<>] // completed to "int(bar)" instead of "bar"
Fixesgolang/go#43375.
Change-Id: I6daef7d23b767f296bdbbc8f47f5b2c972ad9b80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289272
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
In cases like:
type foo struct { a int; b float64 }
foo{b<>}
We were completing to "foo{int(b: <float64>)}" (the problem being the
nonsensical int() conversion).
The expected type at "<>" is int to allow completions to match "a".
When we pass the *types.Var representing "b" through the candidate
matching machinery, we say "Oh, a float64! I can convert that to my
expected type of int!".
Fix by bailing out of candidate matching early if the candidate is a
composite literal struct field name. Field names aren't really objects
you can do anything to.
Fixesgolang/go#43789.
Change-Id: Ie4dab166973dfcdcb519f864532ead1f792d25a3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289130
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
In cases like:
foo<> == 100
We weren't preferring floats at <>. Fix the basic type comparison
logic to know that an untyped int is always compatible with a float.
Fixesgolang/go#44066.
Change-Id: I9cf9bac1632178db100c0a5447351be208b4a2af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289129
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: Hyang-Ah Hana Kim <hyangah@gmail.com>
Field embedding links two objects (a TypeName and a Var) by name,
requiring special handling during renaming. In CL 282932, renaming of
types was made to propagate to uses of their embeddings. However, no
such propagation in the reverse direction was added, meaning that
renaming an embedded field would not rename the corresponding type, and
code could still be left in a non-compiling state.
It should be an invariant that renaming does not change program
behavior. To enforce with field embeddings this we'd need to also rename
the corresponding type, but this seems problematic. If I'm hovering over
the field selector x.T, and rename T, it is surprising that this would
end up renaming a type.
For lack of a better solution, make it an error to rename embedded
fields, but try to provide a helpful error message.
Also handle the blank identifier, for which renaming was giving a
message to "please file a bug".
Marker tests are added for the new errors in rename, but not for
prepareRename. The prepareRename tests were not set up for asserting on
errors -- perhaps that would be a good project for a later CL where we
clean up errors.
Fixesgolang/go#43616
Change-Id: I66c2dd5e531dd102431d1edd443d553687d9ca7e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284312
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: 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>
When renaming a type name, also rename indirect uses of the name as an
embedded field. This is conservatively isolated to just renames for now;
it's not clear to me that users would also want to see uses of embedded
fields as references.
Fixesgolang/go#43616
Change-Id: I41913d037fedb8c27a448cd922eeaf11a02d01f1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282932
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Outgoing callhierarchy didn't handle different functions defined as
field in a struct as separate functions since they were declared by the
same AST node.
This change adds the identifier name to the key, so that a function
must share both declaration node and name to be considered "the same".
Fixesgolang/go#43456
Change-Id: Ifbced98f2e8fc3a303834f7cefbae66829b68d27
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280618
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When trying to get outgoing call hierarchy from an var func like:
func main() {
foo := func() {}
foo()
}
gopls crashed with a panic.
This change makes it return an empty call hierarchy instead.
It also adds support for testing outgoing calls where the expected
result is 0 items, to be able to test this change.
Fixesgolang/go#43376
Change-Id: Icd91bf54cb4fbd5203f5865f0ff9d81365c27d5d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279469
Trust: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When generating a default param name based on a type name, we want to
ignore any package qualifier. For example, if the type is "ast.Node"
we want to generate the variable name "n", so we must ignore the
"ast." qualifier. To do this we use a types.Qualifier that always
returns empty, but qualifyExpr wasn't respecting an empty qualifier
because it is doing manual ast manipulation. However, it seems like
things "just work" if you set a SelectorExpr's "X" to empty
string (i.e. only "Sel" is output when formatting).
Fixesgolang/go#42794.
Change-Id: Ied86b9511e4a9550590417c5a506fe35d561d4f9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275519
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: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
In Go 1.16 error codes as well as start and end positions are added for
go/types errors. This information is temporarily stored in unexported
fields, until we're more confident in the correctness of both the API
and the underlying data.
Read this information using reflection and, if available, use it to set
the corresponding field in compiler diagnostics. This establishes a
positive feedback loop: in most cases this should improve the gopls
diagnostic, and wherever it doesn't we can make a note and fall back on
the old heuristics for that error code.
For golang/go#42290
Change-Id: I37475189cbd14a0a5bcfde163f599c9a7b957372
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268539
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I39d367d0731ea5b7b7bb963699be3003b4fefe86
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274119
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This updates fillstruct to work even when the struct is partially
filled. User supplied fields are preserved but comments are blown away.
Preserving comments appears to be very hard with the current ast
library. One possible option is to do manual string shenanigans, but
after exploring that path it seems like A Bad Idea.
Fixesgolang/go#39804
Change-Id: Iec0bb93db05d4d726dfa6c77a8139f53b14bcc77
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262018
Run-TryBot: Jean de Klerk <deklerk@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Jean de Klerk <deklerk@google.com>
For example:
func wantsInt64(int64) {}
func wantsDuration(time.Duration) {}
func _() {
for i := range []string{} {
// inserts "i" as "int64(i)"
wantsInt64(i<>)
// inserts "i" as "time.Duration(i)"
wantsDuration(i<>)
}
}
Type converted candidates have a significant score penalty so they
should never outrank a directly assignable candidate, other factors
being equal.
To minimize false positive completions, we don't offer converted
candidates if either:
- The candidate is a deep completion into another package. This avoids
random "float64(somepkg.SomeVar)" popping up when completing a
float64.
- Don't offer to convert ints to strings since that's not normally
what the user wants.
After going back and forth I decided not to include the type
conversion in the candidate label. This means you will just see the
candidate "i" in the completion popup instead of "float64(i)". Type
names add a lot of noise to the candidate list.
I also tweaked the untyped constant penalty to interplay better with
the new type conversion penalty. I wanted untyped constants to be
ranked above type conversion candidates since they are directly
assignable, so I reduced untyped constants' penalty. However, to
continue suppressing untyped constants from random other packages, I
applied a similar heuristic to above where we give a bigger penalty if
the untyped constant is a deep completion from another package.
Fixesgolang/go#42764.
Updates golang/go#39207 (untyped constant penalty tweak may improve
this situation).
Change-Id: I565114b3a1c9628285d07200b9dfc45c61e5d898
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272286
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: 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>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I888b33804eec7f38c329ae2e4343b82fcc22f1df
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272166
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>
Rob Findley
Muir Manders
Suzy Mueller
Karthik Nayak
Marwan Sulaiman
johnnyjacobs
pjw
Shoshin Nikita
Andrii Soluk
Hana
Pontus Leitzler
Rebecca Stambler
Jean de Klerk
