Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: support completing to Elem() type for slices, etc. #46045

Closed
muirdm opened this issue May 7, 2021 · 5 comments
Closed

x/tools/gopls: support completing to Elem() type for slices, etc. #46045

muirdm opened this issue May 7, 2021 · 5 comments
Labels
FeatureRequest FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@muirdm
Copy link

muirdm commented May 7, 2021

In the example:

var f func() string
var s []string
var a [1]string
var ch chan string
var m map[int]string

var _ string = <>

It would be nice if <> preferred s, a, ch, and m. We already prefer f. The completion candidate should include the appropriate expression to access the element type, such as s[<>] for indexable things, or <-ch for channels.

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels May 7, 2021
@gopherbot gopherbot added this to the Unreleased milestone May 7, 2021
@findleyr findleyr modified the milestones: Unreleased, gopls/unplanned May 9, 2021
@findleyr
Copy link
Contributor

Sounds good to me. We could theoretically go further (e.g. func() []string), but that's bound to get confusing. One degree of indirection feels about right.

@muirdm
Copy link
Author

muirdm commented May 10, 2021

We could theoretically go further (e.g. func() []string),

I actually have a diff to do that as well. It searches up to three levels of indirection. It required some medium changes to record a proper ordering of the indirections (currently they are represented as separate bools). I'm still playing with it - will keep you apprised.

@gopherbot
Copy link

Change https://golang.org/cl/323449 mentions this issue: lsp/completion: reorganize how we track candidate type mods

@gopherbot
Copy link

Change https://golang.org/cl/323451 mentions this issue: lsp/completion: support completing to Elem() types

@gopherbot
Copy link

Change https://golang.org/cl/323450 mentions this issue: lsp/completion: search deeper for candidate type mods

gopherbot pushed a commit to golang/tools that referenced this issue Jun 9, 2021
"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>
gopherbot pushed a commit to golang/tools that referenced this issue Jun 9, 2021
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>
@golang golang locked and limited conversation to collaborators Jun 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants