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: expose the (experimental) type parameter API for 1.17 with -tags=typeparams #46003
Comments
Change https://golang.org/cl/317549 mentions this issue: |
Change https://golang.org/cl/317472 mentions this issue: |
Change https://golang.org/cl/317849 mentions this issue: |
Our workaround to get and set types.Info._Inferred makes it harder to experiment with the new APIs in x/tools. Instead, just make a copy of the types.Info struct, so that the Inferred field is accessible when the typeparams build tag is set. This is a trivially safe change: the only change when not building with -tags=typeparams is that types.Info._Inferred is removed, and accessing inferred type information goes through an additional layer of indirection. For #46003 Change-Id: I38f2bbb2c80aed28be31d0fe762ccead970476ca Reviewed-on: https://go-review.googlesource.com/c/go/+/317549 Trust: Robert Findley <rfindley@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
I think this can be closed now: CL 317849 is not strictly necessary and can be rebased onto dev.typeparams. |
Change https://golang.org/cl/320149 mentions this issue: |
…pe parameter IDs when possible This is a port of https://golang.org/cl/317472. For #46003. Change-Id: Ie7b8880d43d459527b981ed4f60ee4d80a3cd17a Reviewed-on: https://go-review.googlesource.com/c/go/+/320149 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Change https://golang.org/cl/321269 mentions this issue: |
…en possible Incrementing type parameter subscripts for each type checking pass is distracting for an interactive program where packages are type-checked on each keystroke. We should perhaps hide the type parameter ID altogether, but for now at least add a layer of indirection so that type parameters for a single type-checked package can be stabilized. This change should have no effect on non-generic type checking. For #46003 Change-Id: I60d747e0a2bfb68e7d64e897eac23f609a2a4429 Reviewed-on: https://go-review.googlesource.com/c/go/+/321269 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
When we guarded the new go/* library changes supporting generics with the
typeparams
build constraint (#44933), I took the shortest path to re-exporting the APIs with-tags=typeparams
, only exposing the minimal amount necessary for go/types, gofmt, etc. to work with generics. But as I experiment with generics-supporting features in gopls, I am encountering some ergonomic issues with the current API.Even though they will probably change for 1.18, we should make sure that the 1.17 APIs available with
-tags=typeparams
are sufficient for building experimental tooling.@mdempsky already did some of this in https://golang.org/cl/317029. I'm filing this issue to track a few more CLs I'd like to get in for 1.17. These should all be very low risk changes as they should not affect the build in any meaningful way without
-tags=typeparams
.CC @griesemer
The text was updated successfully, but these errors were encountered: