Skip to content

go/types: need best effort generic func instantiation #51803

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.

Sign up for GitHub

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

Jump to bottom
Closed
muirdm opened this issue Mar 19, 2022 · 9 comments
Closed

go/types: need best effort generic func instantiation #51803

muirdm opened this issue Mar 19, 2022 · 9 comments
Assignees
@findleyr
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.20

Comments

@muirdm
Copy link

muirdm commented Mar 19, 2022

On Go 1.18, I don't seem to get an Instances entry for "foo" in:

func foo[T int](a T) T {
	return a
}

func main() {
	foo[int]() // <-- no Instances entry for this foo
}

It seems to be unhappy because the parameter is absent, however the type parameter is specified which seems like it should be enough to fill in Instances. Without the Instances entry it is difficult for gopls to offer regular parameter completions since gopls can't resolve the instantiated type signature to get the parameter type (unless there is another way?).

/cc @findleyr
@muirdm
Copy link
Author

muirdm commented Mar 19, 2022

Oh I see - if the type checker is happy then the type of the CallExpr.Fun becomes the instantiated signature (so looking in Instances would not be necessary). I'll update the title a bit.

@muirdm muirdm changed the title go/types: types.Info.Instances lacks best effort mapping go/types: need best effort generic func instantiation Mar 19, 2022
@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 20, 2022
@ALTree ALTree added this to the Unplanned milestone Mar 20, 2022
@findleyr findleyr modified the milestones: Unplanned, Go1.19 Mar 21, 2022
@findleyr
Copy link
Member

I agree we for consistency we should record in Instances, but since this has a viable workaround I will put it in the 1.19 milestone. CC @griesemer

(@komuw I'm a little confused by your thumbs down: is there a reason why we shouldn't do this?)

@komuw
Copy link
Contributor

komuw commented Mar 21, 2022 via email

@muirdm
Copy link
Author

muirdm commented Mar 21, 2022

since this has a viable workaround

AFAIK there is no way to get the instantiated *types.Signature when the type params are specified but some func args are missing. My previous comment was realizing that If the type checker resolved the signature in this case I wouldn't need to look at Info.Instances since Info.Types would already contain the instantiated Signature.

But we can filter against the type param constraint, which is better than nothing (maybe that is the workaround you are referring to?).

@findleyr
Copy link
Member

Aha, I did in fact misinterpret your comment. I thought we were somehow recording in Types but not Instances (which doesn't make much sense).

One viable workaround is to CheckExpr the CallExpr.Fun. For example as we do with the infertypeargs analyzer:
https://cs.opensource.google/go/x/tools/+/master:internal/lsp/analysis/infertypeargs/run_go118.go;l=63;drc=2762b18206b1d81e1b5c4ae93377fa732b86bcdf

Not ideal, but possible.

@ianlancetaylor
Copy link
Member

@findleyr What is the current status here? This issue is currently in the 1.19 milestone. Should it move to 1.20? To Backlog? Thanks.

@findleyr
Copy link
Member

Let's move to 1.20.

@findleyr findleyr modified the milestones: Go1.19, Go1.20 Jun 24, 2022
@findleyr findleyr self-assigned this Nov 10, 2022
@findleyr
Copy link
Member

I will reevaluate this for 1.20, but it may slip again.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/451436 mentions this issue: go/types, types2: instantiate call signatures if provided all type args

@gopherbot gopherbot moved this to Done in Release Blockers Nov 18, 2022
@golang golang locked and limited conversation to collaborators Nov 18, 2023
mateusz834 pushed a commit to mateusz834/tgoast that referenced this issue Dec 31, 2024
@findleyr
go/types, types2: ensure signatures are instantiated if all type args
2019fb8 
are provided

Improve the accuracy of recorded types and instances for function calls,
by instantiating their signature before checking arguments if all type
arguments are provided. This avoids a problem where fully instantiated
function signatures are are not recorded as such following an error
checking their arguments.

Fixes golang/go#51803

Change-Id: Iec4cbd219a2cd19bb1bcf2a5c4019f556e4304b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/451436
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@findleyr findleyr

Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Release Blockers
Status: Done
Milestone
Go1.20
Development

No branches or pull requests
6 participants
@ianlancetaylor @ALTree @komuw @gopherbot @muirdm @findleyr