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: need best effort generic func instantiation #51803

Open
muirdm opened this issue Mar 19, 2022 · 5 comments
Open

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

muirdm opened this issue Mar 19, 2022 · 5 comments
Labels
NeedsInvestigation
Milestone

Comments

@muirdm
Copy link

@muirdm 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 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 label Mar 20, 2022
@ALTree ALTree added this to the Unplanned milestone Mar 20, 2022
@findleyr findleyr removed this from the Unplanned milestone Mar 21, 2022
@findleyr findleyr added this to the Go1.19 milestone Mar 21, 2022
@findleyr
Copy link
Contributor

@findleyr findleyr commented Mar 21, 2022

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 komuw commented Mar 21, 2022

@muirdm
Copy link
Author

@muirdm 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
Contributor

@findleyr findleyr commented Mar 21, 2022

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.

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

4 participants