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: expose the (experimental) type parameter API for 1.17 with -tags=typeparams #46003

Closed
findleyr opened this issue May 6, 2021 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@findleyr
Copy link
Contributor

findleyr commented May 6, 2021

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

@findleyr findleyr added the NeedsFix The path to resolution is known, but the work has not been done. label May 6, 2021
@findleyr findleyr added this to the Go1.17 milestone May 6, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/317549 mentions this issue: go/types: expose types.Info.Inferred with -tags=typeparams

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/317472 mentions this issue: go/types: use stable type parameter IDs when typechecking a package

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/317849 mentions this issue: cmd/compile/internal/types2: use Checker-provide type parameter IDs when possible

gopherbot pushed a commit that referenced this issue May 7, 2021
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>
@findleyr
Copy link
Contributor Author

I think this can be closed now: CL 317849 is not strictly necessary and can be rebased onto dev.typeparams.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/320149 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: use Checker-provided type parameter IDs when possible

gopherbot pushed a commit that referenced this issue May 14, 2021
…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>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/321269 mentions this issue: go/types: use Checker-provide type parameter IDs when possible

gopherbot pushed a commit that referenced this issue Jun 4, 2021
…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>
@golang golang locked and limited conversation to collaborators May 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

2 participants