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: add autocomplete for generic function type aliases #52291

Open
nohns opened this issue Apr 12, 2022 · 2 comments
Open

x/tools/gopls: add autocomplete for generic function type aliases #52291

nohns opened this issue Apr 12, 2022 · 2 comments
Labels
FeatureRequest gopls Tools

Comments

@nohns
Copy link

@nohns nohns commented Apr 12, 2022

type Foo[T any] func() T

func Bar[T any](f Foo[T]) {}
// Or 
func FooBar[T any](val T, f Foo[T]) {}

func main() {
    // When writing out this function call, with all the needed type parameters already specified, 
    // gopls should suggest the "func(...) {}" autocomplete, so the function signature is automatically generated.
    Bar[int](/* "func(...) {}" autocomplete should be suggested here. Foo[int] signature would be generated */)

    // The same should happen if the required type parameters can be inferred from already given parameters e.g
    var input string
    FooBar(input, /* "func(...) {}" autocomplete should be suggested here. Foo[string] signature would be generated */)
}

If any help is needed with this proposal I will be happy to look into it.

@gopherbot gopherbot added Tools gopls labels Apr 12, 2022
@gopherbot gopherbot added this to the Unreleased milestone Apr 12, 2022
@jamalc jamalc removed this from the Unreleased milestone Apr 13, 2022
@jamalc jamalc added this to the gopls/unplanned milestone Apr 13, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 16, 2022

Change https://go.dev/cl/400614 mentions this issue: lsp/completion: further improve generic func arg ranking

@muirdm
Copy link

@muirdm muirdm commented Apr 16, 2022

The above cl helps with your first case. I don't think we can fix the second case without changes to go/types.

gopherbot pushed a commit to golang/tools that referenced this issue Apr 26, 2022
In cases like:

    func foo[T int | string](T) {}
    foo[int](<>)

Previously at <> we would favor int and string candidates. This is
because go/types doesn't instantiate foo in this case (for some
reason). Work around the issue by using types.CheckExpr to re-check
the *ast.CallExpr.Fun. CheckExpr seems to do a better than a full type
check in the face of errors.

Updates golang/go#52291
Updates golang/go#52503

Change-Id: Ide436428f3232db2e06ea3cc22ea250edbf28685
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400614
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Tools
Projects
None yet
Development

No branches or pull requests

4 participants