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
Comments
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. |
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?) |
@findleyr
Umh, seems I might have fat fingered that 😃.
Don't mind me.
…On Mon, Mar 21, 2022, 11:18 PM findleyr ***@***.***> wrote:
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
<https://github.com/griesemer>
***@***.*** <https://github.com/komuw> I'm a little confused by your thumbs
down: is there a reason why we shouldn't do this?)
—
Reply to this email directly, view it on GitHub
<#51803 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHMWULXYPK46OBRQ2ZTZCTVBDKTDANCNFSM5RDQL55A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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?). |
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: Not ideal, but possible. |
@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. |
Let's move to 1.20. |
I will reevaluate this for 1.20, but it may slip again. |
Change https://go.dev/cl/451436 mentions this issue: |
On Go 1.18, I don't seem to get an Instances entry for "foo" in:
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
The text was updated successfully, but these errors were encountered: