qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-10-01 08:18:32 -06:00
Code Releases Activity
66c5a5ad76
go/internal/lsp/testdata/summary.txt.golden

24 lines
492 B
Plaintext
Raw Normal View History

use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
-- summary --
internal/lsp: improve literal func completion candidates Previously we were erroneously suggesting a "func() {}" literal in cases like: http.Handle("/", <>) This was happening because saw that the http.HandlerFunc type satisfied the http.Handler interface, and that http.HandlerFunc is a function type. However, of course, you can't pass a function literal to http.Handle(). Make a few tweaks to address the problem: 1. Don't suggest literal "func () {}" candidates if the expected type is an interface type. 2. Suggest named function types that implement an interface. This causes us to suggest "http.HandlerFunc()" in the above example. 3. Suggest a func literal candidate inside named function type conversions. This will suggest "func() {}" when completing "http.HandlerFunc(<>)". This way the false positive func literal is gone, and you still get literal candidates that help you use an http.HandlerFunc as an http.Handler. Note that this particular example is not very compelling in light of http.HandleFunc() which can take a func literal directly, but such a convenience function may not exist in other analogous situations. Change-Id: Ia68097b9a5b8351921349340d18acd8876554691 Reviewed-on: https://go-review.googlesource.com/c/tools/+/205137 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-03 18:47:21 -07:00
CompletionsCount = 215
internal/lsp: improve completion in append() calls Add a special case for append() arguments so we infer the expected type from the append() context. For example: var foo []int foo = append(<>) We now infer the expected type at <> to be []int. We also support the variadicity of append(). Change-Id: Ie0ef0007907fcb7992f9697cb90970ce4d9a66b8 Reviewed-on: https://go-review.googlesource.com/c/tools/+/205606 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-06 12:39:30 -07:00
CompletionSnippetCount = 47
internal/lsp: use available type info for unimported completions Packages that aren't imported in the current file will often have been used elsewhere, which means that gopls will have their type information available. Expose loaded packages in the Snapshot, and try to use that information when possible for unimported packages. Change-Id: Icb672618a9f9ec31b9796f0c5da56ed3d2b38aa7 Reviewed-on: https://go-review.googlesource.com/c/tools/+/204824 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-01 15:59:28 -06:00
UnimportedCompletionsCount = 3
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
DeepCompletionsCount = 5
internal/lsp: search for deep completions across function calls We now continue deep completion search across function calls. The function must take no arguments and return a single argument. For example, when completing "fo<>" you might get candidates such as "foo.bar().baz()". Previously we would stop searching for deep completions when we hit a function call. For example, we would stop at "foo.bar()", never finding "foo.bar().baz()". At the time I was worried about the search scope growing too large, but now that we dynamically limit the search scope there isn't much left to worry about. Change-Id: I48772c154400662876682503c1f58ef6e3dca688 Reviewed-on: https://go-review.googlesource.com/c/tools/+/201222 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org>
2019-10-01 14:36:34 -06:00
FuzzyCompletionsCount = 7
internal/lsp: fix variadic interface completion ranking In cases like: var foo []io.Writer var buf *bytes.Buffer foo = append(foo, <>) we weren't giving "buf" a good score. When comparing the candidate type *bytes.Buffer to the (variadic) expected type []io.Writer we were turning the candidate type into []*bytes.Buffer. However, of course, []*bytes.Buffer is not assignable to []io.Writer, so the types didn't match. Now we instead turn the expected type []io.Writer into io.Writer and compare to *bytes.Buffer. I fixed the @rank test note to check that the candidates' scores are strictly decreasing. Previously it would allow candidates with the same score if they happened to be in the right order. This made it easier to right a test for this issue, but also uncovered an issue with untyped completion logic. I fixed it to do the untyped constant check if _either_ the expected or candidate type is untyped (previously it required the candidate type to be untyped). Fixes golang/go#35625. Change-Id: I9a837d6a781669cb7a2f1d6d3d7f360c85be49eb Reviewed-on: https://go-review.googlesource.com/c/tools/+/207518 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-15 17:14:15 -07:00
RankedCompletionsCount = 26
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
CaseSensitiveCompletionsCount = 4
internal/lsp: add a test to make sure we handle bad imports There was a regression where gopls would not type-check any package with a bad import. This change fixes the regression and adds a test to make sure it doesn't happen again. Change-Id: I3acf0917d46e9444c20135559f057f0ecd20e15b Reviewed-on: https://go-review.googlesource.com/c/tools/+/201539 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Ian Cottrell <iancottrell@google.com>
2019-10-16 17:09:37 -06:00
DiagnosticsCount = 22
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
FoldingRangesCount = 2
FormatCount = 6
internal/lsp/source: start import diffs at byte 0 I assumed that f.Pos() would be the first byte of the file, but it's the position of the package declaration. This kills the file. Just use 0. Fixes golang/go#35458. Change-Id: Ic77c93344c71435ef8e5624c2f2defb619139a15 Reviewed-on: https://go-review.googlesource.com/c/tools/+/206145 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-08 11:43:54 -07:00
ImportCount = 7
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
SuggestedFixCount = 1
internal/lsp: fix and re-enable godef tests None of the godef tests were running due to a mistake in the test harness code. Fix them and re-enable. We decided that the range for an import statement should be the whole import path, not just the first character, so make that change and adjust the PrepareRename tests accordingly. Change-Id: I45756a78f2a1beb3c5180b5f288ce078075624bf Reviewed-on: https://go-review.googlesource.com/c/tools/+/207900 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-19 12:51:46 -07:00
DefinitionsCount = 37
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
TypeDefinitionsCount = 2
internal/lsp: add control flow highlighting inside for loops When the cursor is on a "for" statement or on any branch statement inside the for loop. It will highlight the control flow inside the for loop. Updates #34496 Change-Id: Idef14e3c89bc161d305d4a49fd784095a93bbc03 Reviewed-on: https://go-review.googlesource.com/c/tools/+/208337 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-21 09:26:10 -07:00
HighlightsCount = 22
internal/lsp/source: add support for references in the same workspace When looking for references, look in the entire workspace rather than the same package. This makes the references query more expensive because it needs to look at every package in the workspace, but hopefully it shouln't be user-noticable. This can be made more efficient by only checking packages that are transitive reverse dependencies. I don't think a mechanism to get all transitive reverse dependencies exists yet. One of the references test have been changed: it looked up references of the builtin int type, but now there are so many refererences that the test too slow and doesn't make sense any more. Instead look up references of the type "i" in that file. Change-Id: I93b3bd3795386f06ce488e76e6c7c8c1b1074e22 Reviewed-on: https://go-review.googlesource.com/c/tools/+/206883 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-12 18:16:00 -07:00
ReferencesCount = 7
internal/lsp/testadata/rename: add a test case for renames across packages Renames across packages works as of https://golang.org/cl/206883. Add a test for it. Fixes golang/go#32877 Change-Id: I234fafe95a1060c0ca8d03462bf7b2c241d59e4a Reviewed-on: https://go-review.googlesource.com/c/tools/+/207264 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-14 13:40:29 -07:00
RenamesCount = 22
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
PrepareRenamesCount = 8
SymbolsCount = 1
SignaturesCount = 21
internal/lsp: use import path literal for documentLink range Instead of using the entire import node as the range for the link, use only the link text in the path node itself. This looks better when using a _ or named import, as well as constraining the link to inside the quotes. Fixes golang/go#35565 Change-Id: Ie93d9df993fbd8e0106ca6c3b40e0885355be66b Reviewed-on: https://go-review.googlesource.com/c/tools/+/207137 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com>
2019-11-13 21:53:00 -07:00
LinksCount = 6
use a golden file for the expected test counts This makes it much easier to keep them up to date. It is also less fragile against accidental changes. Change-Id: If119f8527c0896d210650859960e77f3e0fa5a99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/197505 Run-TryBot: Ian Cottrell <iancottrell@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-26 10:54:25 -06:00
Copy Permalink