-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/gopls: support completing to Elem() type for slices, etc. #46045
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
Comments
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. |
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. |
Change https://golang.org/cl/323449 mentions this issue: |
Change https://golang.org/cl/323451 mentions this issue: |
Change https://golang.org/cl/323450 mentions this issue: |
"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>
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>
In the example:
It would be nice if
<>
preferreds
,a
,ch
, andm
. We already preferf
. The completion candidate should include the appropriate expression to access the element type, such ass[<>]
for indexable things, or<-ch
for channels.The text was updated successfully, but these errors were encountered: