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

go/types, types2: record instantiated type when fully instantiated function call is missing arguments #52503

Open
findleyr opened this issue Apr 22, 2022 · 3 comments
Labels
NeedsInvestigation

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Apr 22, 2022

Raised in CL 394017 by @muirdm, the type checker is recording the generic type for a called function if arguments are missing, even if all necessary type arguments are provided, as in the following:

func foo[A int|string](a A) {}

foo[int]() // recorded function type is still func[A int|string](A), even though it should be known to be func(int)

Example: https://go.dev/play/p/xBmccoNdCK_Y

This is probably a low priority (hence not adding the 1.19 milestone), but it would be nice to clean this up as we work on improved type inference.

CC @griesemer

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 24, 2022

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

@thanm thanm added the NeedsInvestigation label Apr 25, 2022
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>
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 30, 2022

Change https://go.dev/cl/403354 mentions this issue: guru: Add a TODO list to the guru cmd.

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 30, 2022

Change https://go.dev/cl/403355 mentions this issue: passes/unusedwrites: Add TODO for how to handle generics.

gopherbot pushed a commit to golang/tools that referenced this issue May 2, 2022
Adds a TODO list for the guru cmd. The main goal is document know
issues that we have not addressed.

Updates golang/go#47326
Updates golang/go#52503

Change-Id: I126b0f06081b606124d89a13f8805fa1ac6e56e3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403354
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopherbot pushed a commit to golang/tools that referenced this issue May 2, 2022
Adds a TODO to explain how to support generics, e.g. fn._Instantiations() should be included once available.

Refactors the run() function to make this simple in the future.

Updates golang/go#52503

Change-Id: Iec84f9bf200cab1026b19e1962165102be0a85ef
Reviewed-on: https://go-review.googlesource.com/c/tools/+/403355
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Guodong Li <guodongli@google.com>
Run-TryBot: Tim King <taking@google.com>
Reviewed-by: Guodong Li <guodongli@google.com>
Auto-Submit: Tim King <taking@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
NeedsInvestigation
Projects
None yet
Development

No branches or pull requests

3 participants