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
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr 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 this to the Go1.17 milestone May 6, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented May 6, 2021

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

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 6, 2021

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

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 6, 2021

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

Loading

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

@findleyr findleyr commented May 13, 2021

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

Loading

@findleyr findleyr closed this May 13, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented May 14, 2021

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

Loading

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

@gopherbot gopherbot commented May 19, 2021

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

Loading

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants